I preface this post with the observation that pretty much any of these solution work for my use case, but might not work for others. In particular, partition images from Windows machines may have all sorts of interesting information contained in cookies and webcaches and the like. I don't care much about, but others might.
I did some research last night. There is a samba user called guest. That might work as there is no password needed. I have not tried it yet.
I tried this one on Sunday. To make it work, I think you need to put something like "guest login = ok" in smb.conf under the Drivebackups share. However, the downside is that anyone with access to your network can read everyone's drive images.
I also worked with cpg and he created a script to pull the first admin user name. Using this script, the user name can be stored as a variable and then added to the boot menu. Leaving off the password option will prompt for a password on boot. This seems to be the best option at this point. It will authenticate the share based on a valid samba share user and secure because you have to enter the password as it is not stored. Then we could identify this as the initial user/password on the app install screen (i.e. user name: Your HDA Admin User/Your HDA Admin Password). Might have to spell it out better in special instructions.
That would certainly work for me. I suspect we can use the ocs_prerun command structure to put up some text saying "Logging on as user XXXX, please enter password" or similar, and then force it all to bomb if the mount fails. (I found another website with a script for doing this last night, but can't find again now...)
I imagine this approach is both simplest to implement and covers most use cases; anyone who's likely to have more than one admin on the network doing bare-metal backup/restores is likely to be sufficiently clued up to follow a wiki page explaining how to change the user.
Does that make sense?
Also thought about creating a standard samba user and password. This could be something like clonezilla/clonezilla and then pass that to the menu. That would mount the drive space based on that user. Just not sure if a new user defaults to rear/write and if it would create a new amahi user.
That would work, but clonezilla/clonezilla is not much more secure than allowing guest logins. As I said above, I don't care much, but others might. (Perhaps others can just go customize the password and put it in the boot menu themselves, based on some wiki instructions?)
Another alternative I read about last night is to create a clonezilla samba only account with a randomly generated password, that you then drop into a creds file (simple text with user/password, but root-only rw access). The file is then tftp'd over (there are examples that do this), and passed as a parameter to mount.cifs.
That way:
* no user/password information on the boot menu
* no wide open samba share
* the process is exceptionally user friendly because there's no risk of a bad password
* advanced users can also engage batch mode if they feel the need for unattended ops
When I was reading it last night, this didn't seem too hard, but I can see it might be fiddly on the install script side.
Have to experiment some more. We are getting close to a solution I believe
Indeed so. Please take the above as just my GBP0.02-worth; I'm happy with any of the solutions you proposed. Let me know if you want me to test anything...
Dave