PDA

View Full Version : NFS user



pieter1602
14-Feb-2015, 02:23
Hoi
Ik heb een vraag over het opzetten van een NFS verbinding met een NAS.Werkt goed maar wat gebeurd er nu eigenlijk.
Ik maak als user :pieter1602 een NFS verbinding aan in YAST met de Nas.Als wie of wat gaat dan die NFS verbinding naar die Nas:\.
Best wel moeilijk uit te leggen!Op de Nas geef je een user dus toestemming voor een Map.maar is degene die op de Nas komt via mijn 13.2 PC , pieter1602 of misschien Root.:|Omdat je in Yast die verbinding maakt

Knurpht
15-Feb-2015, 05:14
NFS bestaat uit 2 componenten: nfsserver en nfs (de client). Het simpelst is om maar even de NFS3 standaard aan te houden:

Aan de serverkant exporteer je wat je elders beschikbaar wilt hebben. Een korte knip uit die van mij:

/disk/Muzickx *(rw,root_squash,sync,no_subtree_check)


De map spreekt voor zich, daarna zie je
root_squash -> wat mag root in de share als die is aangekoppeld op een andere machine. In dit geval wordt door NFS een ander numeriek ID aan root toegekend, zodat de root op een andere machine geen rootrechten heeft op de share
sync -> zorgt ervoor dat client en server continu elkaars situatie actueel houden
no_subtree_check -> NFS gaat niet de hele onderliggende mappenstructuur elk moment testen.

Hoe de client 't doet is te zien in je fstab, je ziet daar een regel met het IP en de nfsexport, met filesystem nfs en wat opties.

E.e.a. betekent dat bijv. jouw gebruiker ook op de NAS moet bestaan (liefst met zelfde UUID).

Heel kort: NFSserver exporteert, NFSclient koppelt de export aan. Jij kunt vervolgens de boel lokaal benaderen. Voor bijv. WEBDAV kun je ook dit soort constructies maken.

Om je even helemaal lekker te maken: mijn wederhelft heeft zo als enige in het docentencorps de hele cloudomgeving van school middels davfs2 aangekoppeld op haar laptop thuis.

Knurpht
15-Feb-2015, 06:51
Nog even over jouw vraag:
- de shares worden standaard aangekoppeld door root.
- omdat jou op de server rechten op een map zijn toegekend, heb je die op de aangekoppelde share ook.

Om te testen:
- maak een nieuwe gebruiker op openSUSE aan, die niet op de NAS bestaat
- probeer de share te benaderen, ingelogd als de nieuwe gebruiker, je moet dan op rechtenproblemen stuiten.

hcvv
15-Feb-2015, 07:31
Hoi

Ik maak als user :pieter1602 een NFS verbinding aan in YAST met de Nas.
Ik hoop dat je na de uitleg van Knurpht begrijpt dat bovenstaande niet kan kloppen. Als je YaST gebruikt ben je al gelijk niet meer user pieter1602. Je bent dan root, er is ook om het root wachtwoord gevraagd. User pieter1602 heeft met het hele mounten niets te maken. Maar als er gemount is (en het maakt niet uit of dat een NFS mount of een schijfmount is), kan pieter1602 misschien daar dingen doen zoals lezen, schrijven, executen. Mits uiteraard de combinatie van eigenaar/groep en permissiebitjes dat toestaan. Hetzelfde als altijd en overal, NFS of niet.

Knurpht
15-Feb-2015, 08:38
Ik hoop dat je na de uitleg van Knurpht begrijpt dat bovenstaande niet kan kloppen. Als je YaST gebruikt ben je al gelijk niet meer user pieter1602. Je bent dan root, er is ook om het root wachtwoord gevraagd. User pieter1602 heeft met het hele mounten niets te maken. Maar als er gemount is (en het maakt niet uit of dat een NFS mount of een schijfmount is), kan pieter1602 misschien daar dingen doen zoals lezen, schrijven, executen. Mits uiteraard de combinatie van eigenaar/groep en permissiebitjes dat toestaan. Hetzelfde als altijd en overal, NFS of niet.

Wat ik jaren geleden niet doorhad, was dat gebruiker knurpht (jawel) met hetzelfde UUID op server en client bestaan moest. Zo kwam ik, om het geklier van moeten onthouden te voorkomen, erop om NIS te gaan gebruiken. Daarvoor werd me aangeraden om alles dan maar 777 te maken, maar ik snapte genoeg om te weten dat dat niet de te bewandelen weg moest zijn.

hcvv
15-Feb-2015, 09:02
Wat ik jaren geleden niet doorhad, was dat gebruiker knurpht (jawel) met hetzelfde UUID op server en client bestaan moest. Zo kwam ik, om het geklier van moeten onthouden te voorkomen, erop om NIS te gaan gebruiken. Daarvoor werd me aangeraden om alles dan maar 777 te maken, maar ik snapte genoeg om te weten dat dat niet de te bewandelen weg moest zijn.
Inderdaad, dat is niet datgene waar mijn vorige post de nadruk op ledge (dat was op het feit dat administratie altijd door root wordt gedaan en nit door een eindgebruiker). Maar ik vermeldde dat uiteraard eigenaarschap en permissies werken.

Dat heeft niet direct tot gevolg dat gebruikers in zo'n NFS server/client hetzelfde moeten heten (in een NAS maak je misschine helemaal geen bebruikers aan), maar je moet die userids/UIDs (en groupids/GIDs) goed in de gaten houden. Als je bijv. twee client systemen hent, wordt het al uitkijken!

En dus is het beste om de gebruikersadministratie van alle systemen gelijk te houden, of op zijn minst de UIDs en GIDs niet dubbel uit te geven. Dus niet op systeem A UID 1000 gebruiken voor de hoofdgebruiker van dat systeem en op systeem B weer 1000 voor een andere gebruiker.

Voor je het weet zit je in de prvéadministratie van een familielid die op het NAS staat te prutten.

pieter1602
15-Feb-2015, 12:18
probeer de share te benaderen, ingelogd als de nieuwe gebruiker, je moet dan op rechtenproblemen stuiten.

Oei probleem ben ik bang, ook met de nieuwe user die niet op de Nas staat kan ik alles doen en zijn er geen rechten problemen.:(

Knurpht
16-Feb-2015, 04:24
Oei probleem ben ik bang, ook met de nieuwe user die niet op de Nas staat kan ik alles doen en zijn er geen rechten problemen.:(

Dan staat er op de NAS iets niet goed. Kun je van de client 's de volgende output posten:


cat /etc/fstab
mount

pieter1602
16-Feb-2015, 07:18
pieter1602@linux-ojay:~> cat /etc/fstab
UUID=9a9cb380-bb43-4120-b088-3ffedb65ab9a swap swap defaults 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 / btrfs defaults 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /opt btrfs subvol=opt 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /srv btrfs subvol=srv 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /tmp btrfs subvol=tmp 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /usr/local btrfs subvol=usr/local 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/crash btrfs subvol=var/crash 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/lib/mailman btrfs subvol=var/lib/mailman 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/lib/named btrfs subvol=var/lib/named 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/log btrfs subvol=var/log 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/opt btrfs subvol=var/opt 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/spool btrfs subvol=var/spool 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/tmp btrfs subvol=var/tmp 0 0
UUID=ee9f6ef7-587f-459f-bebc-40388021ef3e /home xfs defaults 1 2
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /.snapshots btrfs subvol=.snapshots 0 0
192.168.1.42:/volume1/LinuxPC /mnt/OpenSuse nfs4 defaults 0 0




pieter1602@linux-ojay:~> mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=3938844k,nr_inodes=984711,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
/dev/sda2 on / type btrfs (rw,relatime,space_cache)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
/dev/sda2 on /.snapshots type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/tmp type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/spool type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/opt type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/log type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/pgsql type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/named type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/mailman type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/crash type btrfs (rw,relatime,space_cache)
/dev/sda2 on /usr/local type btrfs (rw,relatime,space_cache)
/dev/sda2 on /tmp type btrfs (rw,relatime,space_cache)
/dev/sda2 on /srv type btrfs (rw,relatime,space_cache)
/dev/sda2 on /opt type btrfs (rw,relatime,space_cache)
/dev/sda2 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,space_cache)
/dev/sda2 on /boot/grub2/i386-pc type btrfs (rw,relatime,space_cache)
/dev/sda3 on /home type xfs (rw,relatime,attr2,inode64,noquota)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
192.168.1.42:/volume1/LinuxPC on /mnt/OpenSuse type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.32,local_lock=none,addr=192.168.1.42)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)


Hoi Knurpht

Denk ook dat er op de nas iets niet goed staat weet dat er bij de gedeelde map op de nas bij groepen een vinkje staat bij users en als ik die weg haal kom ik vanaf mijn Pc niet meer op de nas.Is het zinnig als ik ook


cat /etc/fstab
mount doe met dat vinkje bij users weg :\

Knurpht
16-Feb-2015, 13:22
Hoi Knurpht

Denk ook dat er op de nas iets niet goed staat weet dat er bij de gedeelde map op de nas bij groepen een vinkje staat bij users en als ik die weg haal kom ik vanaf mijn Pc niet meer op de nas.Is het zinnig als ik ook

doe met dat vinkje bij users weg :\

Nope, dat heeft geen zin. Ik heb recentelijk geen NASsen onder handen gehad, maar wel 's zo'n "users" optie gezien. Daarmee werd een masker (zie Henk's korte uitleg) gelegd, wat erop neerkomt dat de permissies van 755 naar 775 gezet werden, kortom iedereen die ergens lid is van de groep 'users' ( en dan met hetzelfde group ID als op de NAS ) alles mag op de NAS.

Als jouw gebruiker pieter1602 op jouw openSUSE UID 1000 heeft, moet-ie op de NAS ook bestaan als pieter1602 met UID 1000. Je kunt dat zien in /etc/passwd :
(Van mijn testbakje) Eerst voor de inhoud uit "man passwd" de tweede optie ( een 5 intikken )

name:password:UID:GID:GECOS:directory:shell

knurpht:x:1000:100:Knurpht:/home/knurpht:/bin/bash

Als pieter1602 op de NAS bijv. UID 500 heeft ( er zijn distros die daar beginnen ), dan moet je op je openSUSE bak kijken of dat UID vrij is. Zo ja, dan verander je 't UID van pieter1602 in Yast naar 500. Dit kun je beter niet doen terwijl je ingelogd bent als pieter1602, maar via Yast in de console. Er wordt je gevraagd of de rechten van pieter1602's homedir moeten worden bijgewerkt, dat moet zeker anders heb je geen schrijfrechten meer in je homedir. Als je nu inlogt en verbinding maakt met de NAS moet het goed zijn.

pieter1602
17-Feb-2015, 03:34
Daarmee werd een masker (zie Henk's korte uitleg) gelegd, wat erop neerkomt dat de permissies van 755 naar 775 gezet werden, kortom iedereen die ergens lid is van de groep 'users' ( en dan met hetzelfde group ID als op de NAS ) alles mag op de NAS.

Ja dat lijkt me ook inderdaad wat er gebeurd .

namepassword:UID:GID:GECOS:directory:shell


knurpht:x:1000:100:Knurpht:/home/knurpht:/bin/bash

En ik begrijp je oplossing maar denk dat ik nog geen idee heb hoe ik het bovenstaande kan uitvoeren.:(

Knurpht
17-Feb-2015, 05:49
Je zult dan eerst op de NAS erachter moeten komen welk UID pieter1602 daar heeft. Op sommige NASsen kun je dat UID zelfs op de NAS wel veranderen.

Op je PC kun je dat doen in Yast - Beveiliging en gebruikers - Gebruikers en groepenbeheer - pieter1602 aanklikken - Bewerken - Details. Daar zie je het UID staan, en kun je dat ook wijzigen in het UID dat de NAS van pieter1602 heeft. Tegenwoordig vraagt Yast zelfs niks meer, maar past alles netjes aan.

hcvv
17-Feb-2015, 06:16
Ik volg deze draad eerlijk gezegd niet helemaal precies, maar heb het idee dat iets misschien niet helemaal duidelijk is (is het dat wel, dan sorry).

De username (pieter1602 in dit geval begrijp ik), is niet van veel belang. Het is alleen lokaal bekend. Het is de uid (het nummer) dat van belang is. Als pieter1602 uid 1000 heeft op de PC en hij creëert een bestand op een plek op de NAS (uiteraard op ee plek waar hij dat mag), dan wordt automatisch uid 1000 eigenaar van het bestand. Op de PC zie je dat als pieter1602 (want dat is de voor de mens beter begrijpelijke alias van uid 1000). Op het NAS systeem (feitelijk de NFS server) is ook uid 1000 eigenaar. Als dat een Unix/Linux systeem is kan in /etc/passwd een heel andere username/alias staan (en lokaal kijken levert dus die username als eigenaar op). Er hoeft zelfs helemaal geen bijbehorende /etc/passwd regel te zijn (lokaal kijken geeft dan het uid in plaats van de username bij bijv een ls listing).

Op een andere NFS client kan uid 1000 weer een heel ander username zijn. Dit wordt natuurlijk vervelend als op dat andere systeem uid 1000 ook een andere persoon is. pieter1602 (zijnde Pieter) en de uid 1000 op de andere client (zijn zijn broer Gijs of zo) kunnen dan elkaars bestanden ge/misbruiken.

Van belang is dus dat uids in zo'n groep samenwerkende systemen echt voor fysieke mensen uniek zijn.

Handig is als daar op alle client systemen dezelfde username bij hoort.

Ook handig is als op het NFS server systeem daar dezelfde username bijhoort (al was het maar voor het gemak van de beheerder).

Voor een NAS, waarbij het beheer misschien zeer beperkt is, is het naar mijn mening niet nodig (en misschien ook niet mogelijk) om usernamen aan uid's te hangen.

Ik heb overigens wel veel Unix/Linux NFS servers beheerd (nog steeds enkele) maar heb geen ervaring met NAS. Ik neem aan dat beheer daarvan per type verschilt.

Knurpht
17-Feb-2015, 08:28
NAS = Network Attached Storage.

@Henk: 't zijn meestal (bijna altijd) linux bakjes met NFS, Samba, ssh (en sftp), FTP, webservertje, bedienbaar via een webinterface. Die laatste verschilt per fabrikant, tevens wat je ermee kunt. En, bedankt voor je uitleg, ik denk dat ik jaren geleden al iets gemist heb mbt username, of mezelf heb verteld dat 't moest omdat 't inderdaad wel handiger is. NIS is natuurlijk nog makkelijker.

hcvv
17-Feb-2015, 08:41
NAS = Network Attached Storage.

@Henk: 't zijn meestal (bijna altijd) linux bakjes met NFS, Samba, ssh (en sftp), FTP, webservertje, bedienbaar via een webinterface. Die laatste verschilt per fabrikant, tevens wat je ermee kunt. En, bedankt voor je uitleg, ik denk dat ik jaren geleden al iets gemist heb mbt username, of mezelf heb verteld dat 't moest omdat 't inderdaad wel handiger is. NIS is natuurlijk nog makkelijker.
Uiteraard is NIS een zeer goede oplossing als je zowel de van belang als de handig zijnde zaken in de praktijk wilt invoeren bij een groter aantal systemen. Hoeveel "groter aantal systemen" is hangt niet alleen van het aantal systemen af, maar ook van het aantal te administreren gebruikers en groepen en de aantallen mutaties daarin.

Je moet natuurlijk even in wat NIS studie investeren, maar als je het eenvoudig houdt is het toch zeer goed te doen.

Aan de andere kant, als je één NAS hebt en twee à drie systemen met alleen je gezin als gebruikers is het niet moelijk met de hand te doen. Ik ga bijv. ook geen DNS server opzetten voor drie à vier systemen hier in huis, dat doe ik gewoon in de /etc/hosts en kopie/plak.

pieter1602
18-Feb-2015, 13:08
Dit is voor mij een hoop stevige info die hier en daar best wel moeilijk te begrijpen is :\.Heb putty gedownload en ben op de NAS gaan zoeken naar de users en dat viel niet mee na lang zoeken vond ik pieter1602 met uid van 1026.:)
Heb toen in openSuse de 1000 veranderd in 1026 en een nieuw nfs mountpunt aangemaakt.
Vervolgens heb ik de vinkjes bij users weggehaald iets wat de nas volgens mij uitzichzelf aanpast en weer neerzet.En alleen pieter1602 aan de gedeelde map gegeven opnieuw opgestart.En de vinkjes bleven staan waar ze stonden (niet meer bij users)en met de extra aangemaakte user was de share niet meer te bereiken:).
Dus hcvv en Knurpht bedankt voor het meedenken en de info het lijkt zover te doen wat het moet doen.

pieter1602
19-Feb-2015, 00:30
De username (pieter1602 in dit geval begrijp ik), is niet van veel belang. Het is alleen lokaal bekend. Het is de uid (het nummer) dat van belang is

Is denk ik te zien aan het feit dat ik als pieter1602 niet meer aan mijn oude backups mag komen met de andere uid.Dus maar gewist en nieuwe gemaakt:).

Knurpht
19-Feb-2015, 01:42
Is denk ik te zien aan het feit dat ik als pieter1602 niet meer aan mijn oude backups mag komen met de andere uid.Dus maar gewist en nieuwe gemaakt:).

Nieuwe backups kunnen geen kwaad, maar je had alles weer goed kunnen zetten, door

chown pieter1602 "pad naar backupmap hier invullen zonder aanhalingstekens" -R

hcvv
19-Feb-2015, 04:40
Nieuwe backups kunnen geen kwaad, maar je had alles weer goed kunnen zetten, door

chown pieter1602 "pad naar backupmap hier invullen zonder aanhalingstekens" -R
Ahum, volgens mij

chown -R pieter1602 "pad naar backupmap hier invullen zonder aanhalingstekens"

Knurpht
19-Feb-2015, 07:41
Ahum, volgens mij

chown -R pieter1602 "pad naar backupmap hier invullen zonder aanhalingstekens"

Volgens de man page ook. Maar het werkt wel. Ik heb 't zo geleerd bij NCR, UNIX systemadministration. Daar was een docent, die "Change the directory's permissions, oooops, the content of it is unchanged. Now we repeat this adding the '-R' option and look what happens. Again, nice, but this is not magic.", met een zwaar Schots accent. Zo'n man page waar ik nooit meer naar heb gekeken, omdat ik 't blijkbaar niet nodig had.

hcvv
19-Feb-2015, 08:38
Volgens de man page ook. Maar het werkt wel. Ik heb 't zo geleerd bij NCR, UNIX systemadministration. Daar was een docent, die "Change the directory's permissions, oooops, the content of it is unchanged. Now we repeat this adding the '-R' option and look what happens. Again, nice, but this is not magic.", met een zwaar Schots accent. Zo'n man page waar ik nooit meer naar heb gekeken, omdat ik 't blijkbaar niet nodig had.
Grappig dat het hetzelfde doet. Maar het lijkt me beter om het hier volgens de man page te adviseren. De mensen gaan anders denken dat je altijd zo slordig met de volgorde kunt omspringen, hetgeen zeker niet het geval is.

Knurpht
19-Feb-2015, 12:48
Grappig dat het hetzelfde doet. Maar het lijkt me beter om het hier volgens de man page te adviseren. De mensen gaan anders denken dat je altijd zo slordig met de volgorde kunt omspringen, hetgeen zeker niet het geval is.

Helemaal mee eens. Ik zie wel 's shell scripts (bash) van studenten, daar gaat 't ook nogal 's mis met opties op de verkeerde plek. Ééntje deed 't echt prachtig: SYNOPSIS van commando X in commentaar, variabelen vullen, commando X uitvoeren, volgende commando. Zij vertelde me later dat die scripts nog steeds wel 's inkeek.

Zelf ook maar snel wennen aan de nieuwe plek van "-R". Je zult net zien dat dit wel werkt op openSUSE, maar niet op Debian.

hcvv
20-Feb-2015, 02:05
Dit zit me toch dwars (doorwaakte nacht lol!).

Theorie
======

De man page:

SYNOPSIS

chown [OPTION]... [OWNER][:[GROUP]] FILE...
chown [OPTION]... --reference=RFILE FILE...

Dat betekent volgens mij dat

chown mgi aap -R
het eigenaarschap van de bestanden aap en -R moet wijzigen.
En als bestand -R niet bestaat, verwacht ik een foutmelding.

Praktijk
======


boven:/home/henk/test/t-chown # l
total 16
drwxr-xr-x 2 henk wij 4096 Feb 20 09:57 -R/
drwxr-xr-x 4 henk wij 4096 Feb 20 09:57 ./
drwxr-xr-x 12 henk wij 4096 Feb 20 09:54 ../
drwxr-xr-x 2 henk wij 4096 Feb 20 09:54 aap/
boven:/home/henk/test/t-chown # chown mgi aap -R
boven:/home/henk/test/t-chown # l
total 16
drwxr-xr-x 2 henk wij 4096 Feb 20 09:57 -R/
drwxr-xr-x 4 henk wij 4096 Feb 20 09:57 ./
drwxr-xr-x 12 henk wij 4096 Feb 20 09:54 ../
drwxr-xr-x 2 mgi wij 4096 Feb 20 09:54 aap/
boven:/home/henk/test/t-chown #
De bestandsnaam -R wordt foutief geïnterpreteerd! Zoals jij reeds al "feature" presenteerde.

Ik vrees echter dat dit aanmelden als bug verspilde tijd is.

Knurpht
20-Feb-2015, 06:00
laptop:~ # mkdir -p test/dir
laptop:~ # touch test/file-1
laptop:~ # touch test/dir/file-2
laptop:~ # ls -lR test
test:
totaal 4
drwxr-xr-x 2 root root 4096 20 feb 13:55 dir
-rw-r--r-- 1 root root 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rw-r--r-- 1 root root 0 20 feb 13:55 file-2
laptop:~ # chown knurpht:users test -R
laptop:~ # ls -lR test
test:
totaal 4
drwxr-xr-x 2 knurpht users 4096 20 feb 13:55 dir
-rw-r--r-- 1 knurpht users 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rw-r--r-- 1 knurpht users 0 20 feb 13:55 file-2
laptop:~ # chmod 700 test -R
laptop:~ # ls -lR test
test:
totaal 4
drwx------ 2 knurpht users 4096 20 feb 13:55 dir
-rwx------ 1 knurpht users 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rwx------ 1 knurpht users 0 20 feb 13:55 file-2
laptop:~ # chown root test
laptop:~ # ls -lR test
test:
totaal 4
drwx------ 2 knurpht users 4096 20 feb 13:55 dir
-rwx------ 1 knurpht users 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rwx------ 1 knurpht users 0 20 feb 13:55 file-2

hcvv
20-Feb-2015, 06:27
laptop:~ # mkdir -p test/dir
laptop:~ # touch test/file-1
laptop:~ # touch test/dir/file-2
laptop:~ # ls -lR test
test:
totaal 4
drwxr-xr-x 2 root root 4096 20 feb 13:55 dir
-rw-r--r-- 1 root root 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rw-r--r-- 1 root root 0 20 feb 13:55 file-2
laptop:~ # chown knurpht:users test -R
laptop:~ # ls -lR test
test:
totaal 4
drwxr-xr-x 2 knurpht users 4096 20 feb 13:55 dir
-rw-r--r-- 1 knurpht users 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rw-r--r-- 1 knurpht users 0 20 feb 13:55 file-2
laptop:~ # chmod 700 test -R
laptop:~ # ls -lR test
test:
totaal 4
drwx------ 2 knurpht users 4096 20 feb 13:55 dir
-rwx------ 1 knurpht users 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rwx------ 1 knurpht users 0 20 feb 13:55 file-2
laptop:~ # chown root test
laptop:~ # ls -lR test
test:
totaal 4
drwx------ 2 knurpht users 4096 20 feb 13:55 dir
-rwx------ 1 knurpht users 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rwx------ 1 knurpht users 0 20 feb 13:55 file-2



Zoals gezegd, het is droef. Volgnes de man page zou er:
a) een foutmelding moten komen omdat het bestand -R niet bestaat;
b) alleen van test zouden user:group verander moeten worden en niet van de bestanden daarin.

Gaan we dit doen: Report chown bugs to bug-coreutils@gnu.org ?

Knurpht
20-Feb-2015, 08:53
Zoals gezegd, het is droef. Volgnes de man page zou er:
a) een foutmelding moten komen omdat het bestand -R niet bestaat;
b) alleen van test zouden user:group verander moeten worden en niet van de bestanden daarin.

Gaan we dit doen: Report chown bugs to bug-coreutils@gnu.org ?

Denk ik niet. Je kunt nix met een dir of file genaamd "-R" zonder die als "./-R" te benaderen:


laptop:~ # touch -R
touch: ongeldige optie -- 'R'
Typ 'touch --help' voor meer informatie.
laptop:~ # touch \-R
touch: ongeldige optie -- 'R'
Typ 'touch --help' voor meer informatie.
laptop:~ # touch ./-R


En waar die "-R" staat, maakt niet uit. Niet voor chown, chgrp, chmod:


laptop:~ # chgrp users test/ -R
laptop:~ # ls -lR test
test:
totaal 4
drwx------ 2 knurpht users 4096 20 feb 13:55 dir
-rwx------ 1 knurpht users 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rwx------ 1 knurpht users 0 20 feb 13:55 file-2
laptop:~ # chgrp www -R test/
laptop:~ # ls -lR test
test:
totaal 4
drwx------ 2 knurpht www 4096 20 feb 13:55 dir
-rwx------ 1 knurpht www 0 20 feb 13:55 file-1


test/dir:
totaal 0
-rwx------ 1 knurpht www 0 20 feb 13:55 file-2
laptop:~ #




en dan naar de "-R" dir, we weten dat linux alleen maar files kent, dus dat geloven we wel:



laptop:~ # mkdir -p ./-R/-R
laptop:~ # ls -lR ./-R
./-R:
totaal 4
drwxr-xr-x 2 root root 4096 20 feb 16:48 -R


./-R/-R:
totaal 0
laptop:~ # chown knurpht -R ./-R
laptop:~ # ls -lR ./-R
./-R:
totaal 4
drwxr-xr-x 2 knurpht root 4096 20 feb 16:48 -R


./-R/-R:
totaal 0

Knurpht
20-Feb-2015, 08:55
Ik denk dat de er een regeltje in de man pages bij moet .... Weet zeker dat er ander commando is, waar explicitiet bij staat dat de --opties op elke plek achter het commando mogen staan.

hcvv
20-Feb-2015, 10:24
Denk ik niet. Je kunt nix met een dir of file genaamd "-R" zonder die als "./-R" te benaderen:
[CODE]

Dat ben ik niet met je eens. Ik kan zo'nn bestand bijv. heel goed aanmaken met touch of mkdir en dat heb ik ook gedaan in mijn voorbeeld: Het is ook als bestandsnaam gewoon toegestaan.


henk@boven:~/test/t-chown> l
totaal 12
drwxr-xr-x 3 henk wij 4096 20 feb 17:57 ./
drwxr-xr-x 12 henk wij 4096 20 feb 09:54 ../
drwxr-xr-x 2 henk wij 4096 20 feb 09:54 aap/
henk@boven:~/test/t-chown> mkdir -- -R
henk@boven:~/test/t-chown> l
totaal 16
drwxr-xr-x 4 henk wij 4096 20 feb 17:57 ./
drwxr-xr-x 12 henk wij 4096 20 feb 09:54 ../
drwxr-xr-x 2 henk wij 4096 20 feb 09:54 aap/
drwxr-xr-x 2 henk wij 4096 20 feb 17:57 -R/
henk@boven:~/test/t-chown> touch -- -F
henk@boven:~/test/t-chown> l
totaal 16
drwxr-xr-x 4 henk wij 4096 20 feb 17:57 ./
drwxr-xr-x 12 henk wij 4096 20 feb 09:54 ../
drwxr-xr-x 2 henk wij 4096 20 feb 09:54 aap/
-rw-r--r-- 1 henk wij 0 20 feb 17:57 -F
drwxr-xr-x 2 henk wij 4096 20 feb 17:57 -R/
henk@boven:~/test/t-chown>

En chown kan ze ook gewoon bewerken:

boven:/home/henk/test/t-chown # l
total 16
-rw-r--r-- 1 henk wij 0 Feb 20 17:57 -F
drwxr-xr-x 2 henk wij 4096 Feb 20 17:57 -R/
drwxr-xr-x 4 henk wij 4096 Feb 20 17:57 ./
drwxr-xr-x 12 henk wij 4096 Feb 20 09:54 ../
drwxr-xr-x 2 henk wij 4096 Feb 20 09:54 aap/
boven:/home/henk/test/t-chown # chown -- mgi *
boven:/home/henk/test/t-chown # l
total 16
-rw-r--r-- 1 mgi wij 0 Feb 20 17:57 -F
drwxr-xr-x 2 mgi wij 4096 Feb 20 17:57 -R/
drwxr-xr-x 4 henk wij 4096 Feb 20 17:57 ./
drwxr-xr-x 12 henk wij 4096 Feb 20 09:54 ../
drwxr-xr-x 2 mgi wij 4096 Feb 20 09:54 aap/
boven:/home/henk/test/t-chown #
De fout zit hem er in dat de documentatie niet klopt met wat er gebeurt. Dus of de documentatie is fout, of het programma. Dus altijd een bug.

Het geniepige is dat in de volgende situatie:

boven:/home/henk/test/t-chown # l
total 16
drwxr-xr-x 2 mgi wij 4096 Feb 20 17:57 -R/
drwxr-xr-x 4 henk wij 4096 Feb 20 18:19 ./
drwxr-xr-x 12 henk wij 4096 Feb 20 09:54 ../
drwxr-xr-x 2 mgi wij 4096 Feb 20 09:54 aap/
boven:/home/henk/test/t-chown # chown henk *
boven:/home/henk/test/t-chown # l
total 16
drwxr-xr-x 2 mgi wij 4096 Feb 20 17:57 -R/
drwxr-xr-x 4 henk wij 4096 Feb 20 18:19 ./
drwxr-xr-x 12 henk wij 4096 Feb 20 09:54 ../
drwxr-xr-x 2 henk wij 4096 Feb 20 09:54 aap/
boven:/home/henk/test/t-chown #
het chown statment eerst wordt geëxpandeerd tot

chown henk -R aap
en daarna interpreteert chown de -R als optie. Volkomen tegen de intuitie ook nog eens.

Maar ik ben het met je eens dat aanmelden als bug geen zin heeft (zoals eerder door mij geconstateerd). Men is er waarschijnlijk heel erg van overtuigd dat dit een feature is. Zelfs een "undocumented feature" >:)

Knurpht
20-Feb-2015, 13:28
Maar ik ben het met je eens dat aanmelden als bug geen zin heeft (zoals eerder door mij geconstateerd). Men is er waarschijnlijk heel erg van overtuigd dat dit een feature is. Zelfs een "undocumented feature" >:)

Ik lees net hier er het e.e.a. over http://www.dwheeler.com/essays/filenames-in-shell.html . Ergens wringt 't. Maar "very minor issue", ik laat bestandsnamen nooit met leestekens beginnen.

hcvv
20-Feb-2015, 14:08
Ik ben de link even doorgeraced. Interessant. Ik weet dat het soms (bijna) onmogelijk is om in een script alles goed te verwerken v.w.b. spaties e.d. Vooral als je die bestandsnamen niet zelf in de hand hebt. En hij illustreert dat goed.

Ik begrijp niet wat hij met UTF-8 en non-UTF-8 (waaronder kennelijk de control characters vallen) bedoelt. UTF-8 is alleen een methode om Unicode character waardes (points) om te zetten in één of meer bytes. De methode is zo gekozen dat de ASCII tabel samenvalt met de de eerste 128 characters van de Unocode tabellen en dat blijft zo na omzetten met UTF-8. En die bevat dus ook de van ouds bekende control characters.

Ik gebruik uiteraard ook normaal geen bestandsnamen beginnend met - e.d. Maar hier gaat het om het principe.

Blijft dat chown (en vrienden) volgens de man pagina zouden moeten stoppen met argumenten beginend met - als opties te behandelen na het eerste niet optie argument.

Knurpht
20-Feb-2015, 14:29
Er zjn wel meer van die kleine inconsistenties mbt tot "-", "--", "-- -". Ik ga dan van alles zitten proberen en proberen te beredeneren.

pieter1602
23-Feb-2015, 02:51
Ik noteer ze in iedergeval alle 2 komt het altijd wel goed:),en na even aanzien moet ik zeggen dat uid veranderen zeer nuttig was op PC en Laptop.:)