NB: šis rakstiņš ir paredzēts tiem, kas draudzējas ar pingvīniem, saprot, kas ir Active Directory, Samba, CIFS, Winbind un nano. 🙂 Pārējie var pat neiedziļināties. 🙂
Ja Active Directory tiek veidots, izmantojot Samba kā domēna kontrolieri, ir tāda iespēja – izmantot RFC2307. Šis AD schēmas paplašinājums ļauj precīzi kontrolēt, kādi UID un GID tiek piešķirti lietotājiem un grupām, kā arī ļauj būt drošam, ka UID un GID būs vienādi visos domēna kontrolieros, kā arī domēnam pievienotajos klientu datoros/serveros, kuŗi izmanto Samba. Diemžēl ir viens sīkums, kuŗš var likt izdzert daudz kafijas un krietni palauzīt smadzenes, lai to atrisinātu. Par šo sīkumu un tā novēršanu šodienas rakstiņš. 🙂
Problēma ir ar “Domain Users” grupu uz pirmā domēna kontroliera. Pieņemsim, ka šai grupai ir norādīts GID 10513. Ļoti labi – vienīgi uz šī domēna kontroliera GID vērtība nezin kāpēc tiek ignorēta, un GID tiek rādīts kā 100. Uz brīdi lietas var “nolikt vietā” ar šādu komandu:
net cache flush
Vienīgi – pēc dažām minūtēm GID jau atkal būs 100. Ja domēna kontrolieris tiek izmantots, piemēram, arī kā failserveris (kas gan nav īsti pareizi – Windows pasaulē, kur katra licence maksā bargu naudu, mazam uzņēmumam vai privātpersonai tas vēl būtu attaisnojami, bet brīvās programmatūras pasaulē, kur par licencēm nav jāmaksā un pastāv konteineri un krātiņi 🙂 – nu noteikti nē, tomēr visādi gadās), šāda problēma var būt nu ļoti kaitinoša. Piemēram, ja brīdī, kad GID ir “pareizs” tiek uzstādītas piekļuves tiesības mapēm un failiem, tad, tiklīdz GID ir 100, no šīm tiesībām vairs lielas jēgas nav, jo tās uzstādītas GID 10513 (vai kāds nu tas ir izvēlēts). Pie kam domēnam pievienotajos serveros, kas nav domēna kontrolieri, GID ir “pareizs” – ja CIFS vietā tiek izmantots NFS, tas vēl vairāk visu sarežģī un sačakarē.
Lai atrisinātu šo problēmu, vispirms jāuzzina “Domain Users” grupas SID konkrētajā domēnā, izpildot komandu:
wbinfo -n "Domain Users"
Kā atbilde parādīsies kaut kas šāds:
S-1-5-21-267120627-318859806-3577012832-513 SID_DOM_GROUP (2)
SID sākas ar S- un beidzas ar -513. Tālāk jāievada šāda komanda, aizstājot SID ar to, kuŗu atgrieza iepriekšējā komanda:
ldbedit -e nano -H /var/lib/samba/private/idmap.ldb objectsid=S-1-5-21-267120627-318859806-3577012832-513
Var gadīties, ka jānorāda arī cita idmap.ldb faila atrašanās vieta – konkrētajā piemērā norādīta vieta, kā Ubuntu/Debian tipa sistēmās.
Atvērsies nano teksta redaktors ar šādu rediģējamo saturu:
# editing 1 records
# record 1
dn: CN=S-1-5-21-267120627-318859806-3577012832-513
cn: S-1-5-21-267120627-318859806-3577012832-513
objectClass: sidMap
objectSid: S-1-5-21-267120627-318859806-3577012832-513
type: ID_TYPE_GID
xidNumber: 100
distinguishedName: CN=S-1-5-21-267120627-318859806-3577012832-513
Jāatrod rindiņa, kas sākas ar “xidNumber” un jāaizstāj 100 ar 10513 vai kāda nu tā vēlamā vērtība ir. Fails jāsaglabā un jāaizveŗ teksta redaktors. Tad var izpildīt:
net cache flush
un problēma būs atrisināta.
nano sux, normāliem džekiem ir vim. 🙂