Frequently Asked Questions

Opmerkingen:
- Als je ingelogd bent op een pc die toegevoegd is tot het UGentdomein worden wellicht je Gebruikersnaam en Wachtwoord niet gevraagd
- Buiten het UGentnet (bv. thuis) is het nodig een VPN-verbinding op te zetten voordat je de netwerkschijf verbindt. Behalve met Athena.

Dit zijn de ACL netwerkschijven die DICT ons ter beschikking stelt:
(nota voor Tom: bij de shares met (*) zijn de AD-groepen reeds verplaatst naar "delegations")

Een aantal voordelen t.o.v. de vroegere ge09srv1-netwerkschijven:
* DICT maakt van de data elke nacht een backup die beveiligd is tegen een aanval van ransomware op gekoppelde clients
* je kunt gebruik maken van Vorige Versies

Enkele netwerkschijven hebben een lees-groep en ook een lees/schrijf-groep:
a. mensen in de groep "lezen en schrijven"
- nieuwe mappen en bestanden maken
- bestaande mappen hernoemen
- bestanden lezen (openen)
- bestanden wijzigen en terug opslaan
- bestaande mappen en bestanden verwijderen
- zelf vorige versies van mappen en bestanden raadplegen en terugzetten: http://helpdesk.ugent.be/netdisk/snapshots.php (wees hiermee voorzichtig; denk na of een andere gebruiker van deze netwerkschijf erdoor niet in problemen komt. Bel mij eventueel gerust indien u dit voor het eerst wil gebruiken zodat we de werking samen kunnen bekijken)
- ...
b. mensen in de groep "lezen"
- bestanden lezen:
> openen en dan later een kopie opslaan op een andere locatie
> naar een andere locatie kopiëren

___________________________________________________________________________________________________________

Informatie voor de collega's systeembeheerders die ook ACL-netwerkschijven willen opzetten
en die er net als ik aanvankelijk mee geworsteld hebben ;-)
januari 2018

Onderstaande uitleg bouwt verder op ACL.

I. Stappen voor instellen van ACL-shares waarin alle users in alle mappen zelfde rechten hebben:

1. Vraag ACL-share(s) aan bij DICT

2. Maak groepen aan in AD
Bekijk de voorbeelden op Active Directory Users and Computers - UGent.be - UGentGroups - Delegated - GE - GE33
Maak rollengroepen en persissiegroepen. Gebruik AGDPL zoals hier beschreven.
Belangrijk: Voeg de  AD-groep “GE33.LGP.Share.jouwshare.rw”ook toe aan de groep “GE33.LGP.Share.jouwshare.r”

3. Stel de permissies in op de ACL share
->Let op: Zorg ervoor dat je jezelf niet buitensluit: voeg eerst jezelf toe met Full Control.
-> Of beter: voeg een rolgroep "GE33.GGR.ACLsharesFullControl" met Full Control toe waar je o.a. zelf in zit
Ga naar Verkenner (in Athena) - Shares (S:) - Klik rechts op de naam van de te bewerken share - Properties - Security - Advanced - Change Permissions
Wijzig daar de Permissies volgens de onderstaande screenshots (in dit geval voor de ACL-share "ge33towo")





4. Doe testen met verschillende gebruikers

Opmerkingen:
* Let op niet enkel de grootte van de dataset is beperkt (niet groter dan de quota van de share); ook het aantal bestanden is beperkt. Dit is het gevolg van het maximale aantal inodes. Een work arround kan zijn om groepen bestanden als zip op te slaan op de share.
* Vink enkel opties aan in "Allow"; opties aanvinken in "Deny" verhindert elke andere "Allow" voor de groep in deze share
* Instellen van correcte permissies op ACL shares is belangrijk:
    -> niet te beperkt: de users moeten alle nodige bewerkingen op de shares kunnen doen
    -> niet te open: de users mogen zelf bijvoorbeeld geen permissies kunnen wijzigen


II. Stappen voor instellen van ACL-shares waarin users verschillende rechten in verschillende mappen kunnen hebben:

Op de rootmap GLIPh:
1. om te vermijden dat de gebruikers de submappen kunnen verwijderen:
pas de securities van de root van de share aan voor de groep GE33.LGP.Share.GLIPh zoals volgt:



Bij de onderliggende mappen (1ste niveau):
1. verwijder de LGP die toegang geeft aan de gebruikers op het rootniveau (hier GE33.LGP.Share.GLIPh)
Er komt een melding om de inheriting van de hoger vermelde structuur te vermijden. Druk daarvoor op de knop "Disable inheritance"

2. Voeg de users of groepen toe die wel rw-toegang moeten krijgen in deze map met de Permissions zoals hierboven in de afbeelding "GE33.LPG.Share.ge33towo.rw staan beschreven

3. om te vermijden dat de gebruikers de mappen net onder de root kunnen verwijderen:
pas de securities van deze mappen aan voor alle gebruikers die toegang hebben zoals volgt:

En kies wel specifiek om dit toe te passen in deze folder en subfolders

__________________________________________________________________________________________________________
De historiek van mijn ervaringen met ACL-shares:

11.2019
De gewone share "gliph" werd een ACL-share. Ik maakte daarin voor de eerste keer mappen net onder root met andere toegangsrechten met map
Hierboven aangevuld hoe de securities dienen te worden ingesteld.

12.2018
De shares werden hernoemd naar "ge33-xxx" en de groepen verhuisden van
Active Directory Users and Computers - UGent.be - UGentGroups - Permissions - GE - GE09
naar
Active Directory Users and Computers - UGent.be - UGentGroups - Delegated - GE - GE33
met betere onderverdeling in rollen- en permissiegroegen.

02.01.2018
Configuratie van de ACL-shares en migratie van al onze data van ge09srv1 naar de ACL-shares
 
22.06.2017
Een aantal nieuwe ACL shares gekregen van DICT om op termijn de decentrale vakgroepserver ge09srv1 te vervangen.

27.01.2016
De storage bij DICT crashte vorige vrijdag. Woensdag was het weer in orde maar de beschikbare backup was van enkele dagen  voor vorige vrijdag.
Dus plaatste ik onze eigen backup (van de nacht van donderdag op vrijdag) terug.
Ook alle machtigingen settings waren verdwenen. Johan VC belde me eerst alvorens de share vrij te geven, zo kon ik direct na het vrijgeven de machtigingen opnieuw zetten zoals hieronder (M$ heeft voor een aantal opties de interface gewijzigd).
Er was ook nog een issue met een aantal files waar tovthuyn geen full allow kon op nemen. DICT heeft als oplossing alle machtigingen in deze share verwijderd (tel. Frederic DL) en zo daarna kon ik ze opnieuw instellen.

05.01.2014
Een pilootgroep (6 mensen van GE09) startte met het gebruik van shares\vakgroep\ge09vru.
ISSUES:
- Een persoon kon niet Opslaan (wel Opslaan Als en dan dezelfde naam). Na netwerkschijf unmount / mount op hun client was het oké.
- Een persoon kreeg een melding bij het openen van een SPSS-bestand: "already in use..." (met Word-bestanden was dat niet).
Bestand kon toch wél worden geopend, bewerkt en opgeslagen onder zelfde naam.
Naderhand openen van het bestand kon zonder probleem en de persoon was in de Securities bijgekomen met Full Control.
Om dit op te lossen: Securities aangepast

20.12.2013
mount op Ubuntu (ge08c202) of Debian (hibobbie):
Werkt ok: sudo mount -o username=tovthuyn,domain=UGENT,uid=tovthuyn,gid=tovthuyn //filer/ge09vru /mnt/somedir
Dan rsync -a -v /home/ge/vru /mnt/ge09vruonfiler/data

Werkte niet: sudo mount -t cifs //files/tovthuyn/shares/vakgroep/ge09vru /mnt/somedir -o "username=tovthuyn,password=xxxxx"

Werkt ook: smbclient //filer/tovthuyn -U 'UGENT\tovthuyn'
smb:\> cd shares\vakgroep\ge09vru
Dan werken met smbclientcommando's: get,...

19.12.2013
Frank M installeerde Recycle Bin (prullenbak) op de share.
Net zoals bij windows zelf verschijnt die in de root van de share; maar wel als hidden folder (zoals fme had aangekondigd).
Een paar (wel werkbare) verschillen met de windows Prullenbak:
* het pad naar het gewiste bestand wordt gereproduceerd, waar bij windows de gewiste bestanden in 1 hoop staan met een kolom "Original location";
* er is in het rechtsklikmenu geen "Restore" functie, bestand dient manueel naar de originele locatie te worden gekopieerd/verplaatst

De permissies in de prullenbak staan zo dat  tovthuyn (of een andere lokale gebruiker) ze niet kan verwijderen. En tovthuyn kan die securities niet wijzigen. Kan mogelijks een reden worden om de quota te overschrijden. Later was verwijderen wel mogelijk.

Recycle Bin produceert soms heel lang path: S:\vakgroep\ge09vru\.recycle\Tomtest\.recycle\.recycle\.recycle.
Frank M loste dit op (3.1.13).

Wordt de Recycle Bin meegenomen in de snapshots? Frank M zoekt dit uit.

18.12.2013
* Mounten van \\files\tovthuyn op een XP-client (niet via Athena) geeft foutmelding op ge08vru: "networkpath not found" (andere shares wel ok): lijkt opgelost op 20.12.2013
* Mounten van \\files\tovthuyn moet als user ugent\tovthuyn; met enkel tovthuyn wordt ge09vru niet accessible
* Een gewist bestand kan met Vorige Versie worden 'gerestored' door de folder waaron het stond te restoren naar vorige versie (is wel vervelend als er naast de verwijdering v/h bestand ook andere bestanden in de folder bewust blijvend werden gewijzigd (deze keren ook terug!)
 
18.12.2013
45GB data kopiëren naar ge09vru loopt vast na ong. 10 GB. Geen permissies en access meer gedurende een kort tijdje.
Er kan slechts bestand per bestand worden gewist tot wat data weg is; daarna gaat wissen vlotter.
Volgens Frank M is het GPFS-bestandsysteem dan telkens effe 'weg', mss. door de grootte van de kopie.

Dus op 19.12.2013 een kopie gestart met WinSCP, getrottled tot 512 KiB/s. Had alternatief ook gekund door mounten op hibobbie en rsync.
Stokte na een dikke 1GB, een hoop bestanden geskipt en kopiëerde daarna verder.
Zou kunnen dat de frequente snapshots hiervoor verantwoordelijk zijn (dixit Frank M); Frank M vermindert dat tot: 23h21 en 5h21.

17.12.2013
Securities aangepast:
1.BIJ ge09vru:
Principe: maken dat enkel de gewenste medewerkers toegang hebben tot deze share (en de onderliggende folders en bestanden).

Rechtsklik die folder: Properties - tab Security - Advanced - Change permissions.
Uitvinken van Include inheritable permissions from this object's parent.
Update: In de versie van 2016 is dit: Klik "Disable inheritance"
Ok.
(Als er subfolders bestaan: kies Add to convert and add inherited parent permissions as explicit permissions on this object.)

Voeg jezelf (tovthuyn) toe als Full Control met Apply to: This folders, subfolders and files. Is nodig omdat je anders geen permissies meer kunt wijzigen in objecten die anderen hebben aangemaakt.
Remove Domain Users (Full Control).
Remove Everyone (Read,..).
=> een andere gebruiker kan nu niet meer in die folder (wijziging ook direct aktief; geen vertraging op wijzigen van Properties)

Aanvinken van Replace all child object permissions with inheritable permissions from this object => reeds daar bestaande mappen krijgen de nieuwe permissies

2 nieuwe AD-groepen gemaakt en toegevoegd aan ge09vru:
* Groep GE09.LGP.Share.ge09vru.data.rw krijgt (met Apply to: This folder):
Afbeelding 1 (hier niet ingevoegd wegens achterhaald)

* Groep GE09.LGP.Share.ge09vru.data.r krijgt (met Apply to: This folder):
Afbeelding 2 (hier niet ingevoegd wegens achterhaald)

Deze instellingen zijn nodig opdat niemand met toegang tot de share zelf de securities van ge09vru kan wijzigen; het is de bedoeling dat enkel de lokale sysadmin dat kan; hier tovthuyn.

2. BIJ ge09vru\data
Principe: maken dat de gebruikers die toegang hebben tot ge09vru alle nodige allows hebben voor diverse bewerkingen

De groep GE09.LGP.Share.ge09vru.data.rw heeft Full Control in ge09vru\data en subfolders. Dit is om een issue weg te werken (zie 5.01.14) en is niet erg. In de beproefde hibobbie shares is die mogelijkheid ook.
Ik testte dat personen die niet in GE09.LGP.Share.ge09vru.data.r(w) zitten geen toegang hebben tot bv: \\files\login\shares\vakgroep\ge09vru\data\... => oké!

Opmerkingen:
Een gebruiker die een nieuwe folder of bestand aanmaakt in een subfolder van de share wordt sowieso met zijn individuele Ugentlogin toegevoegd  met Full Control en kan dus permissies wijzigen daarvan.
Dat lijkt op zich geen probleem omdat ge09vru zelf steeds de beperktere permissies behoudt.
Dat kan wel een probleem zijn als je iemand uit de rw-groep verwijdert en enkel behoudt in de r-groep: die heeft dan nog steeds zijn eigen gemaakte folders en bestanden (of de lokale sysadmin zou die permissie moeten wissen voor die objecten).

Nieuwe subfolders en bestanden (aangemaakt door diverse gebruikers) krijgen wel de goede allow-securities => oké!

Wijzigingen in de AD-groep is pas aktief als de gebruiker opnieuw aanmeldt (getest: wordt niet aktief na 2 minuten gewijzigd indien niet afmeldt)

Nieuwe subfolders in die folder mogen wel meer Groups or usernames hebben; andere gebruikers dan hierboven kunnen er toch niet in (nog goed te testen). Bv. de standaard Groups or usernames komen er typisch nog bijkomend in voor:
Domain Users
Everyone

17.12.2013
Bij Hannes Pr uitleg gekregen over naamgeving groepen in AD

1. 'AGDLP' staat voor 'Accounts - Global Groups - Domain Local Groups - Permission'
Uitgebreide informatie over AGDLP kan gevonden worden op volgende links:
http://en.wikipedia.org/wiki/AGDLP
http://www.youtube.com/watch?v=zHHzjjqVhTc
http://technet.microsoft.com/en-us/library/cc755692(v=ws.10).aspx

2. Standaard naamgeving:
-> Rolgroepen die manueel worden onderhouden: <vakgroepcode > + 'GGR.' + <Beschrijving team of afdeling>
-> Permissiegroepen die manueel worden onderhouden: <vakgroepcode> + 'LGP.' + <type permissie> + <permissie waarop> + <optioneel: welke permissie>:
Voorbeeld: GE09.LGP.Share.ge09vru.Folderken.rw
Goed filmpje gekregen van Kurt Bl over AGDLP in AD.

12.12.2013
Deny in permissies heeft voorrang op Allow: als 2 groepen betrekking hebben op een folder (1 waarin een persoon allow heeft en 1 met deny) zal het resultaat Deny zijn.
Toegang tot de shares zelf: individuele opsomming en criteria op LDAP (in ons geval departmentNumber=GE09). AD speelt op dit niveau niet mee.

25.10.2013
Bij Frank M uitleg gekregen: een brainstorm (later deels achterhaald)
LDAP wordt gekopieerd naar AD (is daar niet helemaal hetzelfde)
rechtsklik - properties - security - Edit en Advanced
CREATOR OWNER en CREATOR GROUPS niet wijzigen of verwijderen.
Domain users op Deny zetten: BEST NIET, want dan gooi je jezelf eruit als admin (20.12: wél als je eerst jezelf toevoegt met Full Control).
CREATE GROUPS, OWNER (global of andere geeft problemen) 
keuze met/zonder snapshots 
inheritance: bovenliggende permissies worden door onderliggende folders overgenomen
(wat met later aangemaakte subfolders door de gebruikers?) 
DFS werkt niet -> files 
Frank M kan in nood alle permissies voor een share terugzetten naar read/write voor allen. 
Best verschillende shares aanvragen. Niet een met daarin subshares.
Voordeel: als er een down komt door probleem zijn ze niet allemaal down.

17.10.2013
Frank M maakte voor mij:
een nieuwe share "ge09vru" 100GB (let op: de snapshots vullen dit ook).
Te bereiken via  \\files\<login>\shares\vakgroep\ge09vru
S:\vakgroep\ge09vru  of indien voorgaande niet werkt \\filer\ge09vru
Er zijn 2 verhalen:
1. Groepen maken in AD met adminlogin
2. ACL vakgroepshares: zijn eigenlijk de gewone vakgroepshares met een toegevoegd aspect. Men kan de groepen in AD gebruiken om toegang tot folders en bestanden meer in detail te regelen door in "Eigenschappen" de acls aan te passen.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-