Harm et al,


Harm Paas wrote:
> Collega's,
>
>  zonder in te willen gaan op de geuite voorkeuren met betrekking
> tot distributies wil ik stellen dat, gelet op de rest van de
> inhoud van het concept LWP op dit moment een keuze voor een of
> andere distributeur wel erg voorbarig is : Het leidt alleen maar
> af van de werkelijke problemen die er liggen bij het op RuG-brede
> schaal aanbieden en onderhouden van een Linux werkplek.
> En laten we wel wezen: we zijn allemaal erg tevreden over onze
> "eigen" Linux distributie, ze zijn dus nog steeds allemaal even
> geschikt!
>
> Voorafgaand aan het "Technisch ontwerp" wat momenteel onderwerp
> van discussie is zou ik echter de gevolgde werkwijze enigzins
> willen structureren:
> Een projectvoorstel dat de noodzakelijke eisen aanreikt tot het
> schrijven van een functioneel ontwerp is tot op dit moment
> in de commissie nog niet verschenen.
> Enige tijd geleden heb ik voor een dergelijk ontwerp reeds een
> concept geschreven met als pilot een installatie van de werkplek
> bij FWN,maar het stuk is tot op dit moment nog niet in gebruik.
>
>

Ik geloof dat mijn naamgeving een beetje ongelukkig gekozen is. Ik had
misschien beter "inventarisatie technische randvoorwaarden" kunnen
zeggen. Het idee was om te inventariseren of de verschillende groepen
die nu een linux werkplek aanbieden het eens kunnen worden over een set
technieken ( (of jouw term: selectiecriteria) die zouden moeten worden
gebruikt voor het bouwen van de LWP. Zoals je al terecht opmerkt, met
alle distributies is het bouwen van een LWP mogelijk, maar de manier
waarop verschilt. Het functioneel ontwerp zal dan ook niet door de keuze
van deze technieken beinvloed worden (distributie of storagelocatie
interesseert een gebruiker niet), het technisch ontwerp natuurlijk wel.
Tweede insteek was dan ook om een eerste beeld van de functionele wensen
te krijgen. Jullie kennen je gebruikers natuurlijk goed en kunnen
ongetwijfeld daar wat zinnigs over zeggen.
Met die randvooraarden en gegevens wil ik een eerste schets maken van
een functioneel en een technisch ontwerp. Die eerste schets moet dan
worden voorgelegd aan een aantal kerngebruikers om hun mening te polsen.
aan de hand daarvan worden de schetsen dan uitgewerkt tot een definitief
ontwerp. Dat ontwerp zal deel gaan uitmaken van een projectplan voor
realisatie van de LWP.

> Het lijkt me zinvol dit stuk ter hand te nemen en verder uit
> te werken om uitgaande daarvan te komen tot een vollediger
> invulling van functioneel (en onderliggend technisch) ontwerp,
> zodat we daarna op betere gronden en voldoende onderbouwd tot
> een consensus over de distributie leverancier kunnen komen.
> Het concept is nog steeds actueel en bevat tevens een aantal
> zaken die nog niet aan de orde zijn geweest, ik voeg het daarom
> ongewijzigd toe in de bijlagen.
>
Een mooi stuk, dat kan zeker dienen als basis voor een projectplan.

> Zie voor mijn verdere opmerkingen aangaande het "technisch ontwerp
> LWP" de betreffende bijlage.
>

Een paar vragen/opmerkingen daarover:
-   Begrijp ik goed dat de installatie van een werkplek, groot 5.7GB bij
IWI momenteel in 6 minuten gebeurd?

-   Is het handig zowel een uninstall als een image uitrol mogelijk te
maken? Afhankelijk van werkplek en specifieke noden kan dan gekozen
worden voor een uninstall installatie dan wel het plaatsen van een image

-   Het is duidelijk dat er aanpassingen nodig zijn in de
authenticatieomgeving om een LWP te faciliteren (bijv. de Posix
attributen, groepen om toegang fijnmaziger te kunnen reguleren). Alle
noodzakelijke aanpassingen zullen zoals vermeld uitgevoerd worden

-   Zie ook een eerdere mail van Arjan: ik ben eerlijk gezegd ook nog
niet overtuigd van het nut van jouw data-servers. Het
authenticatiecluster (LDAP servers) is zeer redundant uitgevoerd en zal
op afzienbare termijn losgekoppeld worden van de RUG-tree, hetgeen de
stabiliteit (nu al >99,9% beschikbaar) nog zal verhogen. Plaatsen van
lokale servers zal in mijn optiek eerder leiden tot meer downtime
(grotere kans op storingen door hardware etc). Los daarvan: mijn
"knooppunt servers" waren exact wat jij beschrijft, namelijk een eigen
LDAP kopie (replica) van de centrale user accounts. Wat je wilt is dus
zeker mogelijk, maar je moet me nog wel overtuigen van de wenselijkheid.
Hoe denken de anderen hierover? Arjen, jij ziet geen meerwaarde begrijp ik?

-   Je stukje over centrale storage snap ik niet helemaal geloof ik.
Afhankelijk van de manier waarop we toegang bieden tot centrale storage
is er een aantal beveiligingszaken waar rekening mee moet worden
gehouden, maar dit hoeft niet noodzakelijkerwijze te leiden tot
verminderde user data security.

LaTeX moet natuurlijk meegenomen worden als standaard software.


Met dat al hoop ik nog steeds dat we de lijst met randvoorwaarden verder
aan kunnen scherpen. Uit de test van Jurjen lijkt bijvoorbeeld naar
voren te komen dat NCPMount geen goeie manier is om toegang te bieden
(mogelijk dat tuning nog kan helpen?). Wat betreft installatie is een
combinatie van images en uninstall dus misschien het beste (ik hoor
graag jullie mening). En om nog maar even terug te komen op
distributies: we moeten natuurlijk op zeker moment een keuze maken:
meerdere distributies aanbieden is wat mij betreft geen optie. Nogmaals:
ik ben er van overtuigd dat met alle distributies aan (vrijwel alle)
functionele wensen van gebruikers valt te voldoen. Op grond van
randvoorwaarden die uit ons overleg naar voren zijn gekomen hebben we
vooralsnog de keuze beperkt tot SuSE of Red Hat, ik hoop dan ook dat we
een keuze tussen die twee kunnen maken.
Ik zou dan ook iedereen willen vragen om over beide distributies na te
denken en met een eigen lijstje plussen en minnen te komen (en hopelijk
op grond daarvan een keuze). Van Jurjen heb ik begrepen dat hij een
lichte voorkeur voor SuSE heeft, voornamelijk vanwege bekendheid ermee.
Voor mij geldt hetzelfde en daarnaast is het feit dat SuSE al in
licentie is een plus wat mij betreft.

Daarnaast zou ik iedereen willen vragen mij de contactgegevens te mailen
van één of twee "kerngebruikers" die geraadpleegd kunnen worden voor het
functionele ontwerp, zodat ik wat gesprekken kan gaan plannen.

vrgr
Stefan