Remount read only disk as read write

I would be very surprised if you'll be able to do this; I suspect that the disk "attributes" aren't hot-changed on linode so you'd need to reboot to pick up the change (same as adding disks; it's not a hotplug event).

Does the api mount the image as a loop device? If so, all bets are off…

The api doesn't mount the image you have to mount it yourself like a normal disk. It's not the end of the world if I have to reboot periodically it just would be nice not to have to.

Can't you just leave it R/W at the Linode configuration level and control the R/O status only from within the guest environment? E.g., have your default fstab always mount it R/O and only switch to R/W when needed with the usual remount command?

I suppose this wouldn't be suitable if you're configuring it R/O at the host level due to distrusting the guest environment, but it wasn't clear if that was a requirement. Plus even that would be suspect if there was actually a way to reconfigure the host setup from within the guest.

– David

@db3l:

Can't you just leave it R/W at the Linode configuration level and control the R/O status only from within the guest environment? E.g., have your default fstab always mount it R/O and only switch to R/W when needed with the usual remount command?

I suppose this wouldn't be suitable if you're configuring it R/O at the host level due to distrusting the guest environment, but it wasn't clear if that was a requirement. Plus even that would be suspect if there was actually a way to reconfigure the host setup from within the guest.

– David

It's for aide. So yes distrusting the guest. So far as I know the only way to alter the host from the guest is via the API and the guest wouldn't have the API key. Currently I run aide over NFS but it's darn slow compared to running locally.

@obs:

So far as I know the only way to alter the host from the guest is via the API and the guest wouldn't have the API key.
This is probably a bit extreme (or silly depending on your point of view), but we're already a bit paranoid by trying to protect the guest from itself, so…

Isn't the above a bit of a non-sequitur? If you want to alter the host from the guest using the API, then the guest does have to have the API key, even if it's just while you type it in to run the script. So if the worry is the guest being compromised I'm not sure I'd want to introduce the key into the environment at all, especially since if compromised it exposes much more than just the guest environment.

So at that point making the change externally and rebooting the guest seems much safer anyway, albeit less convenient. Or actually, maybe best is having a completely separate profile to use the disk R/W, so it's never exposed R/W to the risky guest and all changes are made by booting temporarily into a different environment.

-- David

I didn't say the guest edited the host via the api, I just said I used the api since that's the only way of making read only images. The host would be modified externally.

The issue is once the host has been modified externally to allow the image to be written to I can't figure out how to get the guest to then write to it without rebooting.

@obs:

I didn't say the guest edited the host via the api, I just said I used the api since that's the only way of making read only images. The host would be modified externally.
Oops - sorry, I think I got confused by your phrase of "alter the host from the guest" to imply that's what you wanted to do as opposed to what you knew couldn't happen. My bad and please ignore the non-sequitur comment :-)

– David