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.)
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
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
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,
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
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.)