Userbase

Ik zou idd een analyse maken van wat er nu is. Daarna kijken wat er moet blijven en waar we zouden upgraden. Ook zou er dan een nieuwe serveromgeving naast moeten komen om een mooie migratie te doen maar dat moet bekeken worden met onze hostingsponsor natuurlijk.

Kan niet alle custom code (huidige of laatste versie in beta) op github komen waar iedereen er dan iets mee kan doen en kan bijdragen?

Ik weet niet of het slim is om gewoon alle custom code direct op github te smijten.

Als je dat zomaar op github smijt is de kans dat er wat dingen instaan die niet zomaar online mogen .

Laat staan dat er wat "sloppy" code tussenstaat welke voor security problemen zou kunnen zorgen. Best niet zomaar public maar dan misschien met potentiele devs of met invite linkje ofzo.

As stated .. formuleren van de requirements, analyse van de as-is situatie en definitie van een to-be oplossing. ICT Migration project basics ...

Moeten we toch wel kunnen zeker ? E.g. github kan perfect vervangen worden door iets private, er zijn genoeg derivaten/alternatieven.

Voorstel Requirements:
- Code sharing
- RBAC
- OS onafhankelijke code/apps
- LDAP authentication store
- MFA capable
- reverse proxy capable ( problem solved voor http/https mixed content issues )
- WAF
- dedicated ip(‘S)
- Content Migration possibility
....

Voorstel Features Nice to have:
- realtime collaboration/communication
- documentation storage with searchable backend
- trusted authentication (e.g. itsme, social, ...)
- automation add-ins
...

Even een aanzet ... desnoods stapje terug nemen ?

1. Is iedereen van het mgmt team akkoord om de migratie te starten ?
2. Project team definiëren ?
3. Projectplan maken (link met kandidatuur en to-be voorstellen)
...

Voor de duidelijkheid: ik bied hulp aan, geen all in one oplossing.
Ik wil daar gerust ns over samenzitten met iedereen om eerst en vooral te kijken wat er kan gebeuren en hoe lastig dat gaat worden, zowel op hardware als software gebied
In ruil voor mijn hulp hoef ik geen geld (vrijwilliger, nietwaar); wat extra ervaring in omgevingen en procedures waar ik niet vaak mee in aanraking kom is "betaling" genoeg (levenslang leren he).
Full admin access (iets dat vaak onvermijdelijk is op sysadmin niveau) hoeft niet op long term, als men zich daar niet comfy in voelt; temp access voor wat moet gebeuren op een case by case basis is genoeg (want mss idd niet iedereen direct the keys to the kingdom geven).
"Reasonable" NDAs zijn acceptabel.
Allereerst gaan we moeten weten wat nu "is" en wat graag "zou zijn".
Ook mss opsplitsen in "primary" functies (bv de server zelf, het forum, de firewall, etc), die we conservatief en op "production" niveau gaan aanpakken, en eventuele "leuke extras", secondaries die al meer op het niveau van een r&d project kunnen gerund worden.

Ik denk dat mensen in de eerste plaats niet zomaar toegang krijgen tot de "productie" omgeving inderdaad maar dat er gespeeld mag worden in de test omgeving, desnoods in een snapshot VM ofzo".

Anders speel je met vuur, zelfs al heb je backups ter beschikking.

Het voorstel van Sasuke is misschien wel goed in "the long run", maar wat overdreven for now denk ik, nudat we eerst nog moeten kijken wat er allemaal is en wat allemaal mogelijk is.
Ineens overschakelen naar een LDAP auth met MFA, RBAC etc, is al ineens willen lopen voor je kan rechtstaan.

In de eerste plaats blijft het een forum over wat lichte tech, we zijn nog lang niet op het niveau van Tweakers ofzo.

Qua hardware zaten we nog goed dacht ik, maar het waren voornamelijk spiders uit andere landen welke robots.txt niet echt honoreerden en maar zaten te hameren "like no tomorrow". Welke nu wel opgevangen wordt door cloudflare.

Al zien we inderdaad de nadelen van dat certbot niet draait gezien de huidige LE certs op de "echte" server al even verlopen zijn.

Op basis van mijn ervaring : maak baby steps. Voorzie een trajectlijn maar deel het op in kleine projectjes. Werk het ene af voor je aan het volgende begint. Geef wel concrete deadlines aan mensen pm naartoe te werken. Als die niet gehaald worden bekijk dan waarom en of iemand anders kan helpen. Te vaal strand je met vrijwilligers op goede wil maar geen tijd.

Klassiek werkomgeving conflict:
De ITers die van alles het laatste en nieuwste willen (heb zo al een paar ex-consultants achter de kiezen), vs de ITers die conservatiever "if it ain't broken don't fix it" hanteren.
Ik kan me voorstellen dat dit hier exact hetzelfde gaat zijn: een paar die de vlucht vooruit nemen, en een paar die vooral willen consolideren wat werkt en daarna langzaam bekijken wat kan.

Ik ben niet 100% vertrouwd met onze omgeving, maar op zich is de software niet zo speciaal (phpBB), met een paar custom dingen die denk ik in de test omgeving al in orde staan met de laatste phpBB.
De hardware bij EDPnet is ook nog wel OK, al kan misschien een goedkope ssd een klein beetje beterschap brengen.
Ik denk dat gewoon het server OS gekozen moet worden met het oog op eenvoudig onderhoud en makkelijke backups (desnoods één VM in proxmox ofzo om van snapshots te kunnen profiteren, later kunnen daar VM's bijkomen voor aparte SQL server, firewall,...).
Ik zou dus zo snel mogelijk een OS kiezen en zorgen dat dit met minimale inspanningen de basis biedt voor phpBB. Daarna wat we al hebben migreren daar naartoe (+ documenteren). Het dus echt simpel houden om te beginnen, een goede basis.

Vraag me trouwens af waarom die testomgeving nooit een GO heeft gekregen?

Het was ofwel een onvoldoende php versie ofwel een optie in php die niet geactiveerd kon worden op productie.

Idd ga vr een goede basis èbouw dan verder.
Persoonlijk zou ik virtueel gaan op esx waardoor je daarna makkelijker kan uitsplitsen en snapshot mogelijkheden en heel goeie backup kan hebben. Enige dat een nadeel is dat de server hardware supported moet zijn maar kan pergect gechecked worden.

fuserke schreef:Idd ga vr een goede basis èbouw dan verder.
Persoonlijk zou ik virtueel gaan op esx waardoor je daarna makkelijker kan uitsplitsen en snapshot mogelijkheden en heel goeie backup kan hebben. Enige dat een nadeel is dat de server hardware supported moet zijn maar kan pergect gechecked worden.

Nadeel is dat je dan weer een IP per host nodig hebt etc.

Zelf verkies ik proxmox; esx is leuk als je betaalt, niet zo leuk als je gehandicapt bent met de free (or ~cheap) version.
En je kan altijd een firewall steken en de servers op een intern netwerk.
Zo prefereer ik het zelfs.

ITnetadmin schreef:Zelf verkies ik proxmox; esx is leuk als je betaalt, niet zo leuk als je gehandicapt bent met de free (or ~cheap) version.
En je kan altijd een firewall steken en de servers op een intern netwerk.
Zo prefereer ik het zelfs.

ik draai nu proxmox helemaal zo (1 VM is opnsense met de wan port daaraan gekoppeld, proxmox host en alle VMs zitten daarachter).
ben wel nog een beetje met HAproxy aan het klooien om te kijken hoe ik het best forward naar verschillende interne VMs

Opnsense is ook een leuke.
Ik gebruik pfsense vooral, maar het verschil is niet zo groot (en ik ben wel wat verontrust met de rebranding van pfsense in 2.4, je merkt dat netgate de teugels aan het aantrekken is).

OPNSense heeft ook een leuke "history" eigenlijk welke niet zo tof was in de tijd dat het allemaal gebeurde.

Je moet niet vergeten dat er een nederlands bedrijf ook achter OPNSense zit welke evenzeer hun hardware wil pushen.

Maar indertijd toen OPNSense geforked werd van PFSense werd er met hele bergen aan leugens en misinformatie gesmeten aan allerlei verschillende kanten.
Tot near constant vandalism van wikidia pages, mensen welke op de pfsense fora harassed werden en gebanned omdat ze niet veel anders deden dan mensen naar opnsense leiden en leugens verspreiden op die fora etc etc...

Het is tegenwoordig wat minder erg maar de historie van beiden is nogal... gekleurd.

GuntherDW schreef: Het is tegenwoordig wat minder erg maar de historie van beiden is nogal... gekleurd.

ipf

Wordt IPF nog gebruikt in een hedendaagse distro dan?

Ik persoonlijk heb in de 2010-2012 era ergens wel met PFSense gespeeld, maar uiteindelijk gewoon OpenBSD geinstalleerd op m'n server machine at the time want vond de "tweakability" van PFSense best pover. Zelfs vrij kleine aanpassingen waren een hel. In die tijd was IPv6 ook een ramp op PFSense en moest je de webUI vrij extensively modden ook.

Alsook het feit dat PHP als root draaide (toen toch) baarde me serieuze zorgen.

Al was dat toen vectoring op onze lijn eindelijk aan ging ook wel vervangen door een mikrotik dingetje omdat nadien er nog ESX op die server kwam te staan en dat arme E-350 cputje het lastig kreeg met 100MBit .
Je zeg dat I/O usage best hard spiken, zelfs met een Intel NIC.

Al dan nog vind ik PF op OpenBSD toffer om te gebruiken dan die in FreeBSD. De iets andere syntax wat het iets overzichtelijker maakt bijvoorbeeld.
Maar all in all is PF qua traffic filtering software nog altijd best ongeevenaard. IPv4 en 6, inclusief traffic shaping etc in dezelfde file en rules die bijna als "klaar engels" te noemen zijn?
Maargoed, ik had de keuze tussen of een mikrotik dingetje neerploffen of m'n server upgraden. Gezien m'n maten vrij exoteric over die MT's waren toen dacht ik het ook eens een kans te geven en ben er best tevreden van. Ik heb serieuze ergernissen ook maar overall is het best ca va.

GuntherDW schreef:Wordt IPF nog gebruikt in een hedendaagse distro dan?

Was over het gekleurde verleden pfsense/opnsense. De geboorte van pf was al uit ambras met licentie aanpassing van ipf Denk dat zelfs één van de openbsd themesongs erover gaat.

Ah in dat aspect. Jah. Njagoed OpenBSD heeft wel meerdere keren aangetoond dat ze de voorttrekkers van heel de BSD groep zijn eigenlijk. Ze zeggen vaak gewoon "f*** it we zetten het globaal aan en kijken wel wat breekt".
Dat heeft hun wel qua security een goede naam gegeven, zeker op het vlak van ASLR e.d. indertijd. Altijd de eerste om het globaal gewoon aan te zetten.
Heb je binary blob drivers nodig? Well tough luck had je maar andere hardware moeten kopen.

EDIT: Curse words dat gefiltered worden? En enkel in het engels dan? Leuk. Eerste keer dat ik dat tegenkom hier.