Building an embedded Samba4

Tomasz Chmielewski mangoo at wpkg.org
Wed Feb 1 14:42:17 GMT 2006


simo schrieb:

(...)

>>If you wonder how an embedded device can store user profiles, the 
>>answers is simple - it has a USB-stick attached :)
>>As typical USB-sticks can take 100.000 - 1.000.000 writes, depending on 
>>the model, I assume it will be able to live for a couple of years.
> 
> 
> It depends on the type of file system you use, normal file systems tends
> to do more writes in the superblocks and if they are journaled in the
> journal, these parts may get destroyed faster. But I know there are
> filesystems designed with that in mind.

Yes, there is jffs2, but it's for mtd-devices only.
So you can't use it on a USB stick.
Well, you can create an image in a file, but it doesn't get mounted easily:
- you can mount it rw, but a 250 MB image will fill 250 MB RAM
- you can mount it through loop (it doesn't eat that much ram then), but 
it will be ro

At least that's what my research brought - if I'm wrong, I'd be gladly 
corrected.


> Consider also that samba is database driven and works a lot with tdb
> files, where do you keep them ?

I guess it can be safely kept in tmpfs.
Even if the device is disconnected, and the contents of tmpfs is lost, 
it doesn't do any harm to loose *.tdb files, does it?
I mean, if I stop Samba, remove all *.tdb and *.dat files (leaving 
secrets.tdb only), and then start Samba again, it should run fine?
At least that's the case for me. Or I missed something?


> Same here for the openldap database.

If it doesn't change that often, it's fine, so it really depends on the 
userbase.

A database of 100 users/workstations is about 600 kilo big, so 
technically, it could be also put in tmpfs - if there is a LDAP master 
somewhere else (db would be restored from there after a power loss etc.).


>>Right now, it uses about 15-20 MB of RAM (out of 32 MB), although it 
>>runs quite a bit of things:
>>
>>1) slapd + smbd + nmbd + cups for a "normal" Samba file+print server 
>>experience
> 
> 
> samba3 forks a new process at each connection and can suck up 2-4M per
> user ... samba4, in single mode is much more memory conservative.

That's really good (that samba4 can work in a "single process mode").


> On the converse, samba3 is well stable, samba4 is under heavy
> development.

Well, the things are likely to change :)


>>The only thing I don't like about it is that Samba needs to fetch users 
>>not only from LDAP, but also from the system.
>>As this tiny system doesn't have NSS (it's uClibc), I have to generate 
>>/etc/passwd and /etc/group from the LDAP, which is a bit ugly.
> 
> 
> changing samba4 to not require system provided users is much more easy,
> but samba4 has it's own ldap server and doesn't yet support replication.

No replication? Too bad.
I really need replication, so I guess I can't use Samba4 right now.


-- 
Tomasz Chmielewski
http://wpkg.org


More information about the samba-technical mailing list