Hallo Martin,

M.G.R. Vogelaar wrote:
> Beste LWP-ers,
>
> Hieronder een paar opmerkingen over het concept functioneel ontwerp LWP.
> We denken dat het met de definitie van de werkplek wel de goede kant op
> gaat, maar willen zeker als deelnemers van de projectgroep 'oude stijl'
> ook nog eens praten over zaken die nu nog een open staan. Vooral de
> termen 'lokale'- of 'eigen machine' en machine met of zonder 'externe
> toegang' zijn  niet voldoende duidelijk en dus ook nog niet aan
> gebruikers voor te leggen.  En kijken we teveel of juist te weinig naar
> de verschillen tussen een studentenwerkplek en een werkplek voor
> onderzoekers etc.
> Wellicht kunnen we op zo'n bijeenkomst ook nog een paar
> gebruikersscenario's bedenken.
Lijkt me prima

>
> Het is jammer dat Stefan het projectleiderschap niet kan voortzetten.
> Ondergetekende vind het niet een goed teken dat dit project zo snel al
> een personele wisseling kent. We moeten maar even afwachten wat de
> insteek van z'n opvolger is.
De reorganisatie brengt helaas de nodige aanpassingen met zich mee,
waarvan dit er een is. De timing is wat ongelukkig inderdaad. Ik zal iig
proberen zoveel mogelijk betrokken te blijven (tijd en weder dienende).
Ik neem niet aan dat een nieuwe projectleider een grote breuk met het
totnogtoe gedane werk zal betekenen.

>
>
> =======Opmerkingen CONCEPT FO-LWP============================
>
> (mijn opmerkingen beginnen met >>)
>
> - Lokale aanpassingen:
> Aanvullend op het eerste punt: het moet mogelijk blijven om in overleg
> met beheerders op zeer korte termijn lokaal op het werkstation een
> setting aan te
> passen of een nieuw stuk software te installeren.
> >>Voor toekomstige gebruikers is het goed om te weten hoe dat dan
> gaat. Zijn dit 'lokale' beheerders of gaat zoiets via de 'demand
> manager'.
Dat zal denk ik afhangen van de aard van de aanpassing. Op het moment
dat er financien mee gemoeid zijn (nieuwe hardware, licenties, etc) zou
lijkt me de demand manager de aangewezen persoon zijn, maar voor de
meeste aanpassingen de normale ondersteuning aanspreekpunt zijn

>>> Hoe flexibel en fijnmazig is het kanalen-model? Kan een
>>> onderzoeksgroep een eigen kanaal aanvragen?
In mijn optiek absoluut. Wat ik tijdens de inventarisatie veel ben
tegengekomen zijn vakgroepen waar één persoon als een soort
vakgroepbeheerder functioneert. Die persoon heeft iets meer verstand van
linux en verzorgd voor de hele vakgroep de installatie van een
applicatie die specifiek is voor die vakgroep. Momenteel doet hij/zij
dat meestal door fysiek de applicatie te installeren op het ws van de
gebruiker. Dat zou natuurlijk veel mooier via zo'n vakgroepskanaal
kunnen. De applicatie wordt 1x gebouwd, opgenomen in het kanaal en kan
vervolgens door alle gebruikers zelf makkelijk geinstalleerd worden (of
eventueel kan de applicatie zelfs gepushed worden)

>
> - Support voor Windows-only:
> Enkele geïnterviewden gaven aan uit hoofde van hun werkzaamheden
> regelmatig te moeten werken met software die alleen onder windows
> draait. Specifiek
> werden Xopus (de editor van het webplatform) en Powerpoint genoemd. Er
> zal support
> moeten worden geboden voor toegang tot deze diensten.
> >>We zijn bezig met onderzoek naar Xen en KVM voor ondersteuning van
> virtual machines
> >>en verwachten (met recente hardware) een prima integratie op de
> Linux desktop.

Gebeurt hier inmiddels ook veel. Vmware server zou een goeie oplossing
kunnen zijn (gratis), of inderdaad Xen

>
> De Linux Werkplek kent de volgende functionele karakteristieken:
> 5. Overige Applicaties:
> >>Je kunt ook gewoon alles maar installeren. Voor ontwikkelaars weet
> je dan zeker dat je
> >>ook alle 'devel' bibliotheken hebt geinstalleerd. Dat scheelt later
> een boel extra installatiewerk.
Development libraries en compilers zitten wat mij betreft in de
standaard software. Bij overige applicaties moet je denken aan zaken die
specifiek alleen voor een bepaalde faculteit of groep bedoeld zijn

>
> 2 In verband met de noodzaak tot ondersteuning van Internet explorer
> (voor XOPUS) en Powerpoint ligt Crossover  office voor de hand. Een
> combinatie van OpenOffice met een terminal server oplossing of vmware is
> ook mogelijk
> >>Met crossover heb je een flink stuk lokale schijfruimte nodig anders
> is het te traag. We hebben crossover trouwens nog nooit echt stabiel
> gezien. VMWare ligt o.i. meer voor de hand. Xen of KVM bepalen de
> toekomst lijkt het (mits met hardware ondersteuning zoals VT).
Agree, zie ook boven. Xen of vmware onderdeel van de standaard software
maken is een nadrukkelijke optie

>
> 11. Authenticatie:
> Voor toegang tot de werkplek zal gebruik gemaakt worden van het centrale
> RUG account (s-nummer respectievelijk p-nummer). Het voordeel voor de
> gebruiker is
> dat hij in combinatie met centrale storage onafhankelijk van gebruikte
> werkplek/werkstation dezelfde
> desktop en software kan gebruiken en bovendien hiervoor dezelfde
> usernaam-wachtwoord combinatie kan gebruiken die hij ook voor andere
> diensten gebruikt.
> >>Wat doe je met accounts waarvan de gebruiker iets aan z'n eigen
> profiel ( .cshrc o.i.d.) heeft
> aangepast aan een lokale situatie? Wat gebeurt er dan als die
> gebruiker elders inlogt?
Zal in het technisch ontwerp nader duidelijk moeten worden. Wat mij
betreft zou het erg mooi zijn als alles in het profiel centraal
beschikbaar zou zijn. Voorbeeld: een student is aan het werk in een
practicumzaal, maar moet daar weg omdat er practicum gegeven gaat
worden. Hij verhuist naar een andere werkplek, logt in en krijgt weer
exact dezelfde desktop, applicaties en settings.

>>> Hoe ziet een toekomstig gebruiker aan dit ontwerp dat er goed
>>> nagedacht is over een robuust systeem als het gaat om
>>> authenticatie/authorisatie en het serveren van de home directories?
>>> We worstelen zelf al heel lang met het probleem dat werkstations die
>>> prima stand-alone zouden kunnen werken, onbruikbaar worden als de
>>> home directory server uitvalt.
>>> Terugkerend thema is de toegang voor gebruikers zonder p-nummer.
>>> Denk aan gastaccounts, functionele accounts,
> test accounts etc. Dit thema ligt misschien gevoelig, maar verdient
> wel een plaats in het functioneel ontwerp.
In het technisch ontwerp moet dit nader uitgewerkt worden. Indien
mogelijk zou ik een structuur voorstaan waarbij de home-directory lokaal
staat maar vanaf een centrale lokatie (SAN) de profieldirectory etc
geladen worden. Ik heb een figuur aangehecht om je een idee te geven.
Nogmaals, ik weet niet zeker of dit mogelijk is, maar indien ja dan zou
het denk ik een erg mooie oplossing zijn.

>
> 13. Externe toegang tot de werkplek:
> >>Als een student/medewerker overal kan inloggen, wat houdt deze
> persoon dan tegen om voor de lol op 1000 machines Seti-achtige
> applicaties op te starten?
> >>Volgens ons ontkom je niet aan een model voor restricties voor
> externe toegang
>
> >>Nergens is nog iets genoemd over veiligheid. Als je met een firewall
> gaat werken dan moet je voor  externe toegang een soort inlogserver
> aanbieden, vanwaar je verder kunt (met ssh) naar een lokale machine.
> Gebruikers willen graag inzicht hoe ze remote op hun syteem kunnen
> inloggen. Bij Windows speelt dit wellicht minder, maar Unix gebruikers
> vinden over het algemeen externe toegang wel belangrijk.
> MV.
Mee eens, zie ook boven. Niet expliciet genoemd, detailuitwerking volgt
in Technisch Ontwerp, maar deze manier lijkt me ook de beste

vrgr
Stefan