Drobo

New FW still does not fix the passwd reset

Indeed. I have done a bit of digging around and I think I came very close to assemble the whole “reset password and user accounts” picture. It goes something like this:
[list=1]
[]The init process reads /etc/inittab (standard Linux behavior)
[
]/etc/inittab points to /etc/init.d/rcS (line 1)
[]/etc/init.d/rcS calls the script /etc/init.d/enable_var (line 14)
[
]enable_var makes sure that /var is read-writeable, and that the proper folder structure is in place. Important: /var is mounted on flash memory.
[]/etc/init.d/enable_var calls the script /etc/init.d/update_passwd (line 85)
[
]update_passwd reads the file /var/.passwd (no typo, it is really .passwd, you can check on your FS), makes sure that at least ‘root’, ‘avahi’ and ‘nobody’ are there, and if so replaces /etc/.passwd (again not a typo, it is really .passwd)
[]we then return to rcS, which then does all kinds of initializations, but nothing related to /etc/.passwd. The last line calls /usr/bin/nasd, and redirects output to /var/log/nasd.log
[
]From there the proverbial trail goes cold. It seems there is no script that does the copy from /etc/.passwd to /etc/passwd. However, if you run ‘grep -r \.passwd /usr’, you get /usr/bin/nasd back. Surprise, surprise.
[/list]
In summary: remember /var is on flash memory? I think the reason why Drobos are set up this way is because if they need to do support on this thing they can just reflash /var using some external device, and the next time they boot - bam! Root password is reset.

Now, you might be wondering why even have a /etc/.passwd in the first place. That is a very good question. I see no reason why not just copy directly from /var/.passwd directly to /etc/passwd. Who knows?

WARNING: THE INFORMATION BELOW IS DANGEROUS. I HAVE NOT TESTED IT ON MY DROBO FS. FOR ALL I KNOW, IT MIGHT TURN YOUR FS INTO A NICE, EXPENSIVE PAPER WEIGHT. I OFFER NO GUARANTEE ABOUT THIS, PROCEED AT YOUR OWN PERIL.

In any case, the way to “fix” the password reset seems to be simple. First, delete /var/.passwd. The script /var/update_passwd does not overwrite /etc/.passwd if /var/.passwd does not exist. After that, every time you modify /etc/passwd, remember to copy it over /etc/.passwd to replace it.

I have a feeling that if /etc/.passwd does not exist, then nasd won’t try to replace /etc/passwd, so (talking out of my a$$ now) deleting /etc/.passwd should prevent all future password and user account resets.

Symlink maybe?

Worth testing. It depends largely on whether nasd reads its contents and rewrites them, or copies the file. The former will work as expected, but the second would blow away the password file completely.

If you’re going to test this, I’d also see if there’s a way to set up a script that runs on a delay at boot and restores a backup of the passwd file. A dead-man switch of sorts.

I would not try a symlink. I haven’t seen the code of nasd.log, but I would bet that it just copies /etc/.passwd over /etc/passwd (like the update_passwd script). Like diamondsw said, that would nuke the only copy of /etc/passwd.

The only way I would even try such a thing is to have a cron job constantly testing the existence of /etc/passwd and its content, and fixing it as soon as something goes wrong. Unfortunately I’m not that familiar with cron.

O yeah, cron job FTW. I don’t really care, as I don’t see this as a issue in the first place, I was just throwing ideas out there. The only time I see myself using SSH is if I make a python script or a shell script to do something like make a makeshift “drop box” folder, and what to set up cron to run it every hour or what not.

Just to update with some info. I have managed to figure out exactly the hardware inside the DroboFS. It is a Marvell MV78200, whose full spec sheet can be found here.

Turns out I was wrong about the CPU speed. The FS runs at 800 MHz, but only one of the two cores is actually used by the Linux OS. Not as slow as an iPhone 3G, but slower than an iPhone 4. :stuck_out_tongue: