3.0.x 에서는 (다르게 말하자면 Fedora Core 6 용 삼바)
기본적으로 /etc/samba/smbpasswd 라는 파일을 이용해서 계정의 암호를 관리한다.
하지만 3.4.0 으로 가면서 tdb를 사용하게 되는데, 일종의 migration이 필요하게 된다.
조금 간단하게 이야기하자면
FC6 -> Ubuntu 9.10 삼바 마이그레이션 할 경우이다.
Account Import/Export
The pdbedit tool allows import/export of authentication (account)
databases from one backend to another. For example, to import/export accounts from an
old smbpasswd database to a tdbsam
backend:
root# pdbedit -i smbpasswd -e tdbsam
Replace the smbpasswd with tdbsam in the
passdb backend configuration in smb.conf.
SPNEGO (Simple and Protected GSSAPINegotiation Mechanism) is a GSSAPI "pseudo mechanism" that is used to negotiate one of a number of possible real mechanisms.
# smbtree -N
added interface eth0 ip=192.168.10.116 bcast=192.168.10.255 netmask=255.255.255.0
Connecting to host=192.168.10.10
Connecting to 192.168.10.10 at port 445
Connecting to 192.168.10.10 at port 139
Doing spnego session setup (blob length=58)
got OID=1.3.6.1.4.1.311.2.2.10
got principal=NONE
Got challenge flags:
Got NTLMSSP neg_flags=0x608a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x60088215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x60088215
SPNEGO login failed: Logon failure
name_resolve_bcast: Attempting broadcast lookup for name __MSBROWSE__<0x1>
Got a positive name query response from 192.168.10.2 ( 192.168.10.2 )
Got a positive name query response from 192.168.10.241 ( 192.168.10.241 )
Connecting to host=192.168.10.97
Connecting to 192.168.10.97 at port 445
Doing spnego session setup (blob length=16)
server didn't supply a full spnego negprot
Got challenge flags:
Got NTLMSSP neg_flags=0x628a8215
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x60088215
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x60088215
SPNEGO login failed: Logon failure
smbtree에서 트리를 못 받아와서 log level = 3 으로 해서 출력을 해보니 기묘한 약자가 나와서 조사를 해보았다.
(그런데.. 해결책은 어디로.. OTL)
Unfortunately the bug is still observed - i did some additional triaging.
* The bug is seen only when the samba share exported is on a vfat file system
- for ext2 and ext3 the large sized copy succeeds without fail.
* I also tried using the samba package from debian-arm repositories(lenny-stable)
- but there also the problem is seen.
* Even if the error is thrown up - the file is still being copied in the background - or ftruncate'ing in the background (I suspect it is only ftruncating and filling the space with zeroes because of two reasons - one the md5sums do not match afterwards and two the code seems to be doing the same thing) - but as previously stated adding a patch to always call ftruncate64() in sys_ftruncate() does not fix the problem.
# cat log.smbd
[2009/08/15 00:00:07, 0] lib/pidfile.c:121(pidfile_create)
ERROR: smbd is already running. File /usr/local/samba/var/locks/smbd.pid exists and process id 687 is running.
삼바가 구동중에 제대로 종료되지 않고 재가동 될경우
$PIDDIR/smbd.pid
$PIDDIR/nmbd.pid
파일이 남아 있다 보면, 위와 같이 이미 구동중으로 착각을 하고
smbd나 nmbd를 구동하는데 실패를 한다.
fork() / execl() 로 구동시에는
waitpid() 에서 벗어 나지 못하고 멈추는 현상이 발생했다.
결론 : 혹시 모르니 종료가 불확실한 시스템(임베디드?)에서는 삼바 구동 이전에 pid 파일을 지워주도록 하는게 좋을듯 하다.
