Wandering Thoughts archives


Link: A Short History Of Removable Media Behind The Iron Curtain

Pete Zaitcev's A Short History Of Removable Media Behind The Iron Curtain is a fascinating look into the history of (re)movable hard drives in the USSR. Apparently these were far more common there than they were in the west, to the point where it was routine to do this with what the west thought of as fixed hard drives. As a bonus it also includes some information on the early history of byte order independence in Linux filesystems, which Pete Zaitcev was there for.

(I know just enough about the history of computing behind the Iron Curtain to know that it was fairly different from the history in the west. My impression is that there was a fair amount of fascinating hacks and improvisations, and presumably some amount of really impressive original work.)

links/DrivesBehindIronCurtain written at 19:18:13; Add Comment

Sometimes brute force is the answer, Samba edition

Like many places, we have a Samba server so that users with various sorts of laptop and desktop machines can get at their files. For good reason the actual storage does not try to live on the Samba server but instead lives on our NFS fileservers. For similarly good reasons, people don't have separate Samba credentials; they use their regular Unix login and password. However, behind the scenes Samba has a separate login and password system, so we are actually creating and maintaining two accounts for people; a Unix one, used for most things, and a Samba one, used for Samba. This means that when we create a Unix account, we must also create a corresponding Samba account, which is done by using 'smbpasswd -a -n' (the password will be set later).

For a long time we've had an erratic problem with this, in that occasionally the smbpasswd -a would fail. Not very often, but often enough to be irritating (since fixing it took noticing and then manual intervention). Our initial theory was that our /etc/passwd propagation system was not managing to update the Samba server's /etc/passwd with the new login by the time we ran smbpasswd. To deal with this we wrote a wrapper around smbpasswd that explicitly waited until the new login was visible in /etc/passwd and dumped out copious information if something (still) went wrong. Surely we had solved the problem, we figured.

You can guess what happened next: no, we hadn't. Oh, it was clear that some of the problem was /etc/passwd propagation delays, because every so often we could see the wrapper script report that it had needed to wait. But sometimes smbpasswd still failed, reporting simply:

Unable to modify TDB passwd: NT_STATUS_UNSUCCESSFUL!
Failed to add entry for user <newuser>. 

We could have spent a lot of time trying to figure out what was going wrong in the depths of Samba and then how to avoid it, staring at logs, perhaps looking at strace output, maybe reading source, and so on and so forth. But we decided not to do that. Instead we decided to take a much simpler approach. We'd already noticed that every time this happened we could later run the 'smbpasswd -a -n <newuser>' command by hand, so we just updated our wrapper script so that if smbpasswd failed it would wait a second or two and try again.

This is a brute force solution, or really more like a brute force workaround. We haven't at all identified the cause or what we really need to do to fix it; we've simply identified a workaround that we can execute automatically without actually understanding the real problem. But it works (so far) and it did not involve us staring at Samba for a long time; instead we could immediately move on to productive work.

Sometimes brute force and pragmatics are the right answer, under the circumstances.

(It helps that account creation is a rare event for us.)

sysadmin/BruteForceSambaAccountCreation written at 00:27:37; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.