Dažkārt Samba kļūdu informācija var būt patiesi kaitinoša – tā var būt ļoti stipri atkarīga no konkrētās konfigurācijas, vides, Linux kodola un Samba versijas u.t.t. Ja jums ir tik ļoti nepaveicies, ka jums ir salīdzinoši reti izmantota konfigurācija, tad, meklējot risinājumus, var vai nu atrast vecus forumu ierakstus, kuŗiem vairs nav nozīmes, forumu ierakstus bez atbildēm vai kļūdu pieteikumus, kas slēgti, jo “nav iespējams reproducēt problēmu”. Un tomēr – tieši jūsu gadījumā problēma pastāv un nav ne mazākās nojausmas, ko tad īsti esat tādu sliktu sadarījis, lai saņemtu tādu bargu sodu. 🙂
Taisni tā ir arī šajā gadījumā.
Vispirms laikam nedaudz par konkrēto vidi, kuŗā ķibele gadījusies. Mums ir serveris, sauksim to par “server01“, kuŗā darbojas Ubuntu 14.04 LTS un LXD, un ir LXD konteineris, kuŗu sauc “dev1” – tajā darbojas Ubuntu 16.04 LTS. Mūsu tīklā ir Active Directory ar RFC2307 (Unix paplašinājumiem). Lietotājiem un grupām, kuŗiem Unix UID and GID nav norādīti, izmantojam TDB datu bāzi, bet “normāliem” lietotājiem un grupām izmantosim AD servisu ar RFC2307 UID un GID noteikšanai – lai tie būtu vienādi visās *nix sistēmās mūsu tīklā. Vienādu UID un GID esamība ir laba lieta un palīdz failu pārnešanas, sarežģītu piekļuves sarakstu migrācijas un citos gadījumos.
Pēc Samba uzstādīšanas un konfigurēšanas mūsu konteinerī (dev1), tika konstatēts, ka pie tā nav iespējams pieslēgties ne ar vienu klientu – ne ar cifs failsistēmas draiveri, ne ar smbclient, ne arī no Windows darbstacijas. Piemēram, ar smbclient notiek tā:
root@dev1:~# smbclient -Ualvils -Wdevlat //dev1/alvils
Enter alvils's password:
Domain=[DEVLAT] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu]
tree connect failed: NT_STATUS_CONNECTION_DISCONNECTED
Vienlaikus failā /var/log/samba/log.smbd parādās šādas rindas:
[2016/10/05 12:14:37.813685, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'smbd' finished starting up and ready to serve connections
[2016/10/05 12:14:51.277701, 0] ../source3/lib/util.c:789(smb_panic_s3)
PANIC (pid 796): sys_setgroups failed
[2016/10/05 12:14:51.278618, 0] ../source3/lib/util.c:900(log_stack_trace)
BACKTRACE: 26 stack frames:
#0 /usr/lib/x86_64-linux-gnu/samba/libsmbregistry.so.0(log_stack_trace+0x1a) [0x7ff6256d871a]
#1 /usr/lib/x86_64-linux-gnu/samba/libsmbregistry.so.0(smb_panic_s3+0x20) [0x7ff6256d87f0]
#2 /usr/lib/x86_64-linux-gnu/libsamba-util.so.0(smb_panic+0x2f) [0x7ff626461f1f]
#3 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0xffb0a) [0x7ff626016b0a]
#4 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0xffb85) [0x7ff626016b85]
#5 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0xec66e) [0x7ff62600366e]
#6 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x117fe1) [0x7ff62602efe1]
#7 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x118a11) [0x7ff62602fa11]
#8 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(make_connection+0x220) [0x7ff62602ff10]
#9 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(reply_tcon_and_X+0x651) [0x7ff625fde831]
#10 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x1121d7) [0x7ff6260291d7]
#11 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x113f23) [0x7ff62602af23]
#12 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x11558c) [0x7ff62602c58c]
#13 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(run_events_poll+0x167) [0x7ff62434b917]
#14 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(+0x2cb77) [0x7ff62434bb77]
#15 /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x8d) [0x7ff622f7ad3d]
#16 /usr/lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7ff622f7aedb]
#17 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(smbd_process+0x718) [0x7ff62602d8e8]
#18 /usr/sbin/smbd(+0x8e12) [0x55d529fcae12]
#19 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(run_events_poll+0x167) [0x7ff62434b917]
#20 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(+0x2cb77) [0x7ff62434bb77]
#21 /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x8d) [0x7ff622f7ad3d]
#22 /usr/lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7ff622f7aedb]
#23 /usr/sbin/smbd(main+0x1899) [0x55d529fc9099]
#24 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7ff622bc7830]
#25 /usr/sbin/smbd(_start+0x29) [0x55d529fc9199]
[2016/10/05 12:14:51.281561, 0] ../source3/lib/dumpcore.c:303(dump_core)
dumping core in /var/log/samba/cores/smbd
Problēma redzama 4. rindiņā:
PANIC (pid 796): sys_setgroups failed
Par šādu ķibeli bija iespējams atrast dažus vecus forumu ierakstus un kļūdu pieteikumus, tomēr tie visi bija par Samba 3.x un Linux 3.5. Proti, kad tika izlaista kodola versija 3.5, tajā tika ieviestas dažas izmaiņas funkcijas sys_setgroups() darbā – tika atgriezta kļūda, ja funkcijai tika nodots GID -1, un Samba taisni to arī reizēm mēdza darīt. Un tomēr – šī problēma ir veca (ap 2012. gadu) un jau sen ir salabota, tādēļ modernās Samba versijās tai nemaz nebūtu jāparādās.
Tika atrasti arī daži forumu ieraksti par to, ka arī tagad ļaudis mēdz saskarties ar šo problēmu, un ļoti līdzīgā variantā, kā šis konkrētais gadīums, tomēr tie bija ieraksti bez atbildēm vai arī tādām atbildēm kā “Jā, man arī ir šāda problēma. Lūdzu, kāds palīdziet!”
Un tā it kā neliela ķibele pārvērtās par lielu problēmu. Loģiski, tā kā bija lasīts par Samba pagātnes problēmām ar kodolu, tika nolemts atjaunināt servera Linux kodolu, lai tas atbilstu Ubuntu 16.04 LTS. Tas bija vienkārši, tā jebkuŗā gadījumā ir laba lieta un izrādījās, ka tas itin nemaz nepalīdz – tomēr, ja vēlaties to izdarīt, izlasiet Ubuntu Wiki lapu angliski.
Pēc nelielām pārdomām par to, kas un kāpēc nestrādā, tika noskaidrots, ka sys_setgroups funkcija izpilda tādu kā rezolvēšanu – tai tiek nodots grupu ID saraksts un tā atgriež šai grupai piederīgo lietotāju sarakstu. Līdz ar to radās pārliecība, ka kādus no šiem grupu ID sistēma “nesaprot” vai uzskata tos par nederīgiem, tādēļ atgriež kļūdu, izraisot smbd procesa nokāršanos.
Kamēr “normālā” Linux sistēmā nav nekādi praktiski UID un GID lietojuma ierobežojumi, mums jāatceras, ka darbojamies LXD konteinerī. Tā kā konteineri un konteineru hosts kopīgi lieto to pašu failsistēmu, katram lietotājam, kas darbina konteinerus, tiek piešķirts savs namespace – tas ir, bāzes vērtība, no kuŗas sākas konteinera “iekšējie” UID un GID. Piemēram, normālā situācijā root lietotāja UID ir 0. Ja konkrētā LXD konteinera īpašnieka namespace sākas ar, piemēram, 100000, root lietotājs konteinera iekšpusē joprojām būs 0, bet no hosta viedokļa šī lietotāja UID būs 100000. Konteinera lietotāja UID 1000 hostā būs 101000 u.t.t. Šīs bāzes vērtības, kā arī pieejamo UID/GID skaits tiek norādīts divos hosta failos – /etc/subuid un /etc/subgid. Konkrētajā situācijā hostā šie faili izskatījās tā:
/etc/subuid:
lxd:231072:65536
/etc/subgid:
lxd:231072:65536
Tas ir, “lxd” lietotāja palaistajiem konteineriem bāzes vērtība būs 231072 un konteineriem ir atļauts ne vairāk, kā 65536 UID un GID. To var viegli pārbaudīt pašā konteinerā:
root@dev1:~# touch test
root@dev1:~# chown 65535 test
root@dev1:~# ls -all test
-rw-r--r-- 1 65535 root 0 Oct 5 12:16 test
root@dev1:~# chown 65536 test
chown: changing ownership of 'test': Invalid argument
root@dev1:~# ls -all test
-rw-r--r-- 1 65535 root 0 Oct 5 12:16 test
Proti, vispirms izveidojam failu “test“, tad tā īpašnieku norādam UID 65535. Atceramies, ka mums ir 65536 UID un GID vērtības – no 0 līdz 65535. Mēs veiksmīgi varam uzstādīt UID uz 65535, bet ne uz 65536, kuŗš mūsu gadījumā ir “ārpus diapazona”. Mjā, tā ir laba norāde, tikai kādus UID un GID grib izmantot mūsu mīļotā Samba? To viegli var ieraudzīt failā /etc/samba/smb.conf; atbilstošā faila daļa:
idmap config DEVLAT:backend = ad
idmap config DEVLAT:schema_mode = rfc2307
idmap config DEVLAT:range = 500-4000000
idmap config DEVLAT:default = yes
idmap config *:backend = tdb
idmap config *:range = 4000001-5000000
Redzams, ka diapazons 500-4000000 ir rezervēts AD modulim, bet 4000001 līdz 5000000 – TDB. Lai gan lietotāji, kam Unix atribūti norādīti korekti, visdrīzāk būs ar UID, kas mazāks par 65536, dažām grupām – piemēram, BUILTIN\administrators vai BUILTIN\users, GID’us aprēķina TDB. Tas nozīmē, ka mums vienkārši vajag paplašināt atļauto UID un GID diapazonu mūsu konteinerim.
Konteineris tika izslēgts un tika veiktas izmaiņas failos /etc/subuid un /etc/subgid:
/etc/subuid:
lxd:231072:5000000
/etc/subgid:
lxd:231072:5000000
Tad tika restartēts LXD serviss, lai tas ņemtu vērā jauno konfigurāciju, pēc kā tika iedarbinās mūsu konteineris::
root@server01:~# service lxd stop
root@server01:~# service lxd start
root@server01:~# lxc start dev1
Tagad varam pārliecināties, ka konteinerā UID un GID varam izmantot ar daudz lielākām vērtībām:
root@dev1:~# touch test
root@dev1:~# chown 65536 test
root@dev1:~# ls -all test
-rw-r--r-- 1 65536 root 0 Oct 5 12:21 test
root@dev1:~# chown 200000 test
root@dev1:~# ls -all test
-rw-r--r-- 1 200000 root 0 Oct 5 12:21 test
Un, tavu brīnumu – smbclient arī strādā:
root@dev1:~# smbclient -I10.5.1.16 -Ualvils -Wdevlat //dev1/alvils
WARNING: The "acl check permissions" option is deprecated
Enter alvils's password:
Domain=[DEVLAT] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu]
smb: \>
Secinājumi – dīvaino Samba nokāršanos izraisīja vairāki faktori:
- Active Directory vide
- Konkrētā Samba konfigurācija ar lieliem UID/GID diapazoniem
- Samba darbināšana LXD konteinerā, kuŗam bija noklusētais UID/GID diapazons, proti – 65536, kamēr Samba vēlējās, lai diapazons būtu 5000000.
Kā redzams, šādi gadījumi nav pašsaprotami un prasa dziļāku situācijas izpēti, un risinājums arī nav diez ko pašsaprotams un atbilstošs sākotnējai problēmai. Un tomēr – pietiekošas zināšanas par šo tematu un neliela pasmadzeņošana ļaut arī tādas problēmas atrisināt. Šis rakstiņš tika uzrakstīts, lai palīdzētu citiem, kuŗi var iekulties līdzīgās problēmās.
Comments are closed.