[ArchLinx] group-id's probleemloos aanpassen?*

[Sijmen]

Hallo,

Na het vorige topic van mij op dit forum, heb ik een stuk verder doorgezocht. Veel gelezen over onder anderen LDAP en OpenLDAP, e.d.. Maar nu is mijn doel een beetje veranderd: ik hoef geen loginserver meer voor Windows clients, maar voor Linux client. Nog beter, client/server hebben dezelfde distributie: Arch Linux.

Ik wou beginnen met een loginserver, en ben dus een beetje gaan rondneuzen op fora en irc, en uiteindelijk bleek het toch het prettigst om een script te maken, dat wordt opgestart bij het inloggen. Dan kom je op zo'n soort script uit:

code:

echo "Fetiching boot script from server..."
scp bootloader@mijnserver:~/bootscript /root/.bootscript
sh /root/.bootscript

(Dit natuurlijk na ervoor gezorgt te hebben dat de user bootloader bestaat, en dat deze vanaf de client password-less in kan loggen.)

Dan kan het bootscript script bijv. het volgende zijn:

code:

echo "Loggin on to the network..."
scp bootloader@mijnserver:~/passwd /etc/passwd
scp bootloader@mijnserver:~/shadow /etc/shadow
scp bootloader@mijnserver:~/hosts /etc/hosts

# ik heb ne nog niet zo verdiept in nfs, maar het idee is duidelijk 
# (ik weet dus niet of dit zo kan werken)
mount -t nfs mijnserver:/home/users /home

echo "Done"

Ik heb nu 1 probleem en 1 vraag:

1. (probleem)
Ik probeerde uit te zoeken of de uid's en gid's overeen komen met de client en de server waarmee ik wil gaan testen, maar het blijkt dat de group file van de client enigzins afwijkt - waaronder een dubbele gid:

code:

root::0:root                      root::0:root
bin::1:root,bin,daemon            bin::1:root,bin,daemon
daemon::2:root,bin,daemon         daemon::2:root,bin,daemon
sys::3:root,bin                   sys::3:root,bin
adm::4:root,daemon                adm::4:root,daemon
tty::5:                           tty::5:
disk::6:root                      disk::6:root
lp::7:daemon                      lp::7:daemon
mem::8:                           mem::8:
kmem::9:                          kmem::9:
wheel::10:root                    wheel::10:root
ftp::11:                          ftp::11:
mail::12:                         mail::12:
                                > slocate:x:21:
smmsp::25:                        smmsp::25:
                                > mysql:x:89:
                                > audio:x:92:
                                > optical:x:93:
nobody::99:                       nobody::99:
users::100:                       users::100:
gdm:x:101:                      | httpd:x:101:

De groepen gdm en httpd conflicteren met elkaar. Is het veilig om de id van de gdm groep te veranderen? Ik weet nl. wel dat de httpd groep veelvuldig gebruikt wordt en dat dus niet al te veilig kan zijn.

2. (vraag)

Is dit een slimme en/of veilige methode?

Voor de duidelijkheid: ik heb weldegelijk gezocht op fora/internet naar het gid gebeuren, maar kreeg erg weinig waar ik iets mee kon. Zelfde voor de vraag. Daarnaast wil ik gewoon wat meningen hebben van mensen die er ook argumenten bij hebben e.d.

/edit:
scp gebruikt natuurlijk niet -l <user> maar <user>@host

[ Voor 5% gewijzigd door Sijmen op 12-01-2005 14:04 ]

[Spider.007]

In theorie moet je gid's zonder problemen kunnen veranderen aangezien lookups altijd via de groups-file adhv de naam moeten gaan; en niet dmv het bijbehorende nummertje worden gecontroleerd. Start op in een lage runlevel (1 ofzo) waarin je zoweinig mogelijk services draait; en pas dan het gid aan. (bijv 101 > 102) Vervolgens doe je een `find -group 101 -exec chgrp 102 {} \;` en je bent klaar?

[Sijmen]

Spider.007 schreef op woensdag 12 januari 2005 @ 12:50:
In theorie moet je gid's zonder problemen kunnen veranderen aangezien lookups altijd via de groups-file adhv de naam moeten gaan; en niet dmv het bijbehorende nummertje worden gecontroleerd. Start op in een lage runlevel (1 ofzo) waarin je zoweinig mogelijk services draait; en pas dan het gid aan. (bijv 101 > 102) Vervolgens doe je een `find -group 101 -exec chgrp 102 {} \;` en je bent klaar?

Ik wist niet eens dat je find automatisch kon laten exec-en en op group finden.. heel slim gedaan (ik had de manpage moeten lezen). Heel erg bedankt in ieder geval, dit ga ik zeker proberen.

[Zwerver]

title change met dank aan spider.007

[Sijmen]

Zwerver schreef op woensdag 12 januari 2005 @ 16:12:
title change met dank aan spider.007

Oh.. maar het ging niet alleen om de groups, dat was maar een deel. Ik wil ook graag weten of dit (met scp de users/passwords/groups overhalen) wel een goede oplossing is. En om het nu nog maar wat breder te maken - of hier al een kant-en-klare oplossing voor is

[Spider.007]

Sijmen schreef op woensdag 12 januari 2005 @ 16:15:
[...]


Oh.. maar het ging niet alleen om de groups, dat was maar een deel. Ik wil ook graag weten of dit (met scp de users/passwords/groups overhalen) wel een goede oplossing is. En om het nu nog maar wat breder te maken - of hier al een kant-en-klare oplossing voor is

Dus je wilt weten of het een goed idee is om dmv scp een 'loginserver' te maken? En wat zou die 'loginserver' dan precies moeten doen; wat wil je er precies mee? Wat is het doel van deze hele opzet? Dat mis ik een beetje in je verhaal

[Sijmen]

Spider.007 schreef op woensdag 12 januari 2005 @ 17:13:
[...]

Dus je wilt weten of het een goed idee is om dmv scp een 'loginserver' te maken? En wat zou die 'loginserver' dan precies moeten doen; wat wil je er precies mee? Wat is het doel van deze hele opzet? Dat mis ik een beetje in je verhaal

Ah, ok, ik zal het wat duidelijker maken.

Ik wil centraal op 1 computer de users en groups bijhouden. Daarnaast zou het mooi zijn als ook de home directories op diezelfde computer staan (centraal dus). Het gaat om niet meer dan een paar clients, het is eigenlijk vooral om het eens gedaan te hebben - het hoeft niet in een productieomgeving te gaan werken oid.

Dat is het eigenlijk wel zo'n beetje

[_JGC_]

persoonlijk zou ik iets als NIS of nss_ldap/pam_ldap gebruiken om users in sync te houden tussen meerdere systemen. Voor archlinux kan je het een en ander voor nss_ldap en pam_ldap uit de incoming directory op de FTP server halen, maar deze zijn IMHO beetje buggy (DESTDIR werd in mijn geval niet meegenomen, je files gaan zonder packagemanagement zo naar / als je niet oppast bij het bakken)