Skript, trassel med rättigheter

[civilpolisen]

Med hjälp av Fusion Directory är det tänkt att vi ska hantera alla användare... och alla datorer.
Vi har EN server och så ska det vara. Vi har just nu också EN klient att öva sig på och så ska det inte vara! :-)

På servern har jag valt att lägga alla sex nycklar, sex filer, i en mapp under /usr/share/fusion_directory/

I skriptet som sen körs på klienten ska man hämta dessa filer, men det är där det skär sig med rättigheterna!
Vad gör jag för fel!? Hur ska det vara!?
Skriptet är just nu väldigt pratigt och här är den delen av skriptet som rör själva kopieringen och som just nu får representera "the weak point"... på vanlig svenska...!

Kod: Markera allt

COPY FROM FD-SERVER TO LOCAL PATH /TMP
scp -rp fd.company.se:/usr/share/fd-company-se/deathstar-ssl /tmp
scp: /usr/share/fd-company-se/deathstar-ssl/mycacert.pem: Permission denied
scp: /usr/share/fd-company-se/deathstar-ssl/deathstar_slapd_key.pem: Permission denied
scp: /usr/share/fd-company-se/deathstar-ssl/mycakey.pem: Permission denied
scp: /usr/share/fd-company-se/deathstar-ssl/deathstar_slapd_cert.pem: Permission denied
scp: /usr/share/fd-company-se/deathstar-ssl/certinfo.ldif: Permission denied
scp: /usr/share/fd-company-se/deathstar-ssl/deathstar.info: Permission denied

Datorn deathstar är en helt tom server på vårt LAN som bara innehåller EN sak... ja, om det ens vore så väl!
Vad göra med rättigheterna!? Vad göra så det passar?

[Osprey]

Omöjligt att svara på, så länge vi inte vet vilka rättigheter som gäller för filerna i "/usr/share/fd-company-se/deathstar-ssl/".

Du anger inte heller vilken användare du vill att kopieringen ska köras som på servern, utan bara "fd.company.se:/path/to/file".
Den fulla syntaxen för detta är:

Kod: Markera allt

[[user@]host:]/path/to/file

Problemet med att du även behöver ett lösenord, tror jag att du kan fixa med "sshpass" om du installerar det...

[civilpolisen]

OK, jag har fått detta att fungera nu. Det fungerade tidigare och nu fungerar det igen.
När jag skapar hierarkin sätter jag "chmod 775" på mappen... och då blir det rätt, till sist!

Alla filerna ska vara på sin plats nu, tror jag... med rätt rättigheter, tror jag...

Kod: Markera allt

civilpolisen@deathstar:~$ cd /etc/ldap/
civilpolisen@deathstar:/etc/ldap$ ls -la
total 44
drwxr-xr-x   2 root root  4096 jun 15 11:20 .
drwxr-xr-x 100 root root  4096 jun 15 11:22 ..
-rw-r-----   1 root root   191 jun 15 11:20 certinfo.ldif
-rw-r-----   1 root root   116 jun 15 09:44 deathstar.info
-rw-r-----   1 root root  1537 jun 15 09:44 deathstar_slapd_cert.pem
-rw-r-----   1 root root  5628 jun 15 09:44 deathstar_slapd_key.pem
-rw-r-----   1 root root  1428 jun 15 09:44 mycacert.pem
-rw-r-----   1 root root 10719 jun 15 09:44 mycakey.pem
civilpolisen@deathstar:/etc/ldap$ 

[civilpolisen]

Uppföljning:
Detta fungerar:

Kod: Markera allt

civilpolisen@ldapserver:~$ ldapwhoami -x -H ldap://fd.company.se
anonymous

civilpolisen@deathstar:~$ ldapwhoami -x -H ldap://fd.company.se
anonymous

Däremot fungerar det inte att logga in med en LDAP-användare... av nån konstig anledning! Det retar mig en aning, milt uttryck!
Jag letar efter anledningen!

Undrar om det jobbigaste är att det inte ens finns ett felmeddelande att ta sig ann...!!

Kod: Markera allt

civilpolisen@ldapserver:/var/log$ cat ldap.log | grep civilpolisen

Jun 16 14:48:46 ldapserver slapd[5255]: => access_allowed: read access to "uid=civilpolisen,ou=people,ou=company,dc=nodomain" "userPassword" requested
Jun 16 14:48:46 ldapserver slapd[5255]: => access_allowed: search access to "cn=civilpolisen,ou=groups,ou=company,dc=nodomain" "objectClass" requested
Jun 16 14:48:46 ldapserver slapd[5255]: => send_search_entry: conn 1021 dn="cn=civilpolisen,ou=groups,ou=company,dc=nodomain"
Jun 16 14:48:46 ldapserver slapd[5255]: => access_allowed: read access to "cn=civilpolisen,ou=groups,ou=company,dc=nodomain" "entry" requested
Jun 16 14:48:46 ldapserver slapd[5255]: => access_allowed: read access to "cn=civilpolisen,ou=groups,ou=company,dc=nodomain" "cn" requested
Jun 16 14:48:46 ldapserver slapd[5255]: => access_allowed: read access to "cn=civilpolisen,ou=groups,ou=company,dc=nodomain" "gidNumber" requested

Det är väldigt många raderoch jag har inte tagit med alla. De andra raderna följer samma mönster.

[johanre]

OK, jag har fått detta att fungera nu. Det fungerade tidigare och nu fungerar det igen.
När jag skapar hierarkin sätter jag "chmod 775" på mappen... och då blir det rätt, till sist!

Alla filerna ska vara på sin plats nu, tror jag... med rätt rättigheter, tror jag...

Nja, det fungerar egentligen bara för att du låter alla användare som är inloggade på deathstar se allting i den katalogen. Sen kanske det inte gör något ur ditt perspektiv, för att du är den enda användaren på systemet? Men jag tycker nog att det är fel sätt att lösa problemet på.

Däremot fungerar det inte att logga in med en LDAP-användare... av nån konstig anledning! Det retar mig en aning, milt uttryck!
Jag letar efter anledningen!

Undrar om det jobbigaste är att det inte ens finns ett felmeddelande att ta sig ann...!!

Kod: Markera allt

civilpolisen@ldapserver:/var/log$ cat ldap.log | grep civilpolisen

Du letar nog efter fel uttryck, testa med t.ex:

Kod: Markera allt

grep -E 'error|warning' /var/log/ldap.log

[civilpolisen]

Kod: Markera allt

civilpolisen@ldapserver:~$ grep -E 'error|warning' /var/log/ldap.log
Jun 18 20:48:21 lynx slapd[5255]: connection_read(23): TLS accept failure error=-1 id=1445, closing
Jun 18 20:48:21 lynx slapd[5255]: connection_read(23): TLS accept failure error=-1 id=1446, closing
Jun 18 20:48:21 lynx slapd[5255]: connection_read(23): TLS accept failure error=-1 id=1447, closing
Jun 18 20:48:21 lynx slapd[5255]: connection_read(23): TLS accept failure error=-1 id=1448, closing
Jun 18 20:48:21 lynx slapd[5255]: connection_read(23): TLS accept failure error=-1 id=1449, closing
Jun 18 20:48:21 lynx slapd[5255]: connection_read(23): TLS accept failure error=-1 id=1450, closing
Jun 18 20:48:21 lynx slapd[5255]: connection_read(17): TLS accept failure error=-1 id=1418, closing
Jun 18 20:48:21 lynx slapd[5255]: connection_read(21): TLS accept failure error=-1 id=1442, closing
Jun 18 20:56:17 lynx slapd[5255]: connection_read(17): TLS accept failure error=-1 id=1452, closing
Jun 18 20:56:17 lynx slapd[5255]: connection_read(17): TLS accept failure error=-1 id=1453, closing
Jun 18 20:56:17 lynx slapd[5255]: connection_read(17): unable to get TLS client DN, error=49 id=1454
Jun 18 20:56:28 lynx slapd[5255]: connection_read(17): unable to get TLS client DN, error=49 id=1455
Jun 18 20:58:14 lynx slapd[5255]: connection_read(17): unable to get TLS client DN, error=49 id=1456
Jun 18 20:58:15 lynx slapd[5255]: connection_read(17): unable to get TLS client DN, error=49 id=1457
Jun 19 02:39:52 lynx slapd[5255]: connection_read(19): TLS accept failure error=-1 id=1475, closing
Jun 19 03:31:53 lynx slapd[5255]: connection_read(17): TLS accept failure error=-1 id=1492, closing
Jun 19 03:36:12 lynx slapd[5255]: connection_read(17): unable to get TLS client DN, error=49 id=1493
Jun 19 03:58:09 lynx slapd[5255]: connection_read(17): unable to get TLS client DN, error=49 id=1496

Jag har loggat in på morgonen, men loggen flyttar inte på sig! Varför visar den bara saker från i natt!?
Vår LDAP server ligger dock på Internet så ... det kan tänkas vara anrop från annan dator än de som vi förfogar över.

* * * * * *

Nja, det fungerar egentligen bara för att du låter alla användare som är inloggade på deathstar se allting i den katalogen. Sen kanske det inte gör något ur ditt perspektiv, för att du är den enda användaren på systemet? Men jag tycker nog att det är fel sätt att lösa problemet på.

Vi pratar om olika saker. Ursäkta mig! "Skriptet fungerar" menade jag. Du har helt rätt med att jag är den enda användaren på deathstar! En server uppsatt i vårt LAN med fast IP för ändamålet, att testa skript för installation av LDAP via SSSD.

[johanre]

Kod: Markera allt

civilpolisen@ldapserver:~$ grep -E 'error|warning' /var/log/ldap.log
Jun 18 20:48:21 lynx slapd[5255]: connection_read(23): TLS accept failure error=-1 id=1445, closing

Detta är alltså felaktiga LDAP anslutningar, där någon försöker göra en okrypterad LDAP anslutning till en LDAP server som pratar krypterad LDAP

Jag har loggat in på morgonen, men loggen flyttar inte på sig! Varför visar den bara saker från i natt!?

Nja, det är inte riktigt det som händer. Det du ser är alltså urval ur loggen på rader som innehåller orden "error" eller "warning". Så utifrån grep kommandot, så har det inte varit några felaktiga ldap anslutningar efter "Jun 19 03:58:09"

Vi pratar om olika saker. Ursäkta mig! "Skriptet fungerar" menade jag. Du har helt rätt med att jag är den enda användaren på deathstar! En server uppsatt i vårt LAN med fast IP för ändamålet, att testa skript för installation av LDAP via SSSD.

Men OK, då kan vi anse den frågan löst - bra!

[civilpolisen]

Ja! Frågan är löst i den meningen att skriptet fungerar felfritt med avseende på rättigheter! Men det går inte att logga in...! Den detaljen!
Var haltar det!? Jag vet ju inte var jag ska leta!
Förslag mottages tacksamt! :-)

[johanre]

Hjälper gärna till men behöver nog veta lite mer för att förstå ditt problem. Vad är det egentligen du försöker åstadkomma? Försök beskriva vilka delar försöker kommunicera med vad, och var du förväntar dig ett inloggningsförsök.

[civilpolisen]

Tack!
Ja, jag vet inte riktigt vad problemet är...

Vi har en LDAP server som vi idag använder för inloggning i andra sammanhang. Jag har satt upp en dator / server i vårt LAN för att kunna testa SSSD inloggningen med.

Jag har två skript vid installation av ny klient, en ny dator. Jag har följt manualen på denna sidan:
https://ubuntu.com/server/docs/service-ldap-with-tls

Just nu har jag ett skript att köra på servern och ett att köra på klienten. Det fungerar till synes smärtfritt att köra och att sjösätta dessa saker.

Inloggningen borde fungera och det gjorde den också sen tidigare, men nu med skripten och allt trassel med rättigheter fungerar det inte att logga in på LDAP via SSSD. Där är vi just nu...

Loggen visar inget som ser fel ut.... men tittar jag ens i rätt logg!?