> This is exactly like immutable files until you go back to boot -s. > Such a pain in the ass to deal as soon as you want to play with > machines to which you don't have direct physical access. >
You could set a flag which runs a script before the securelevel is raised on the next boot but you would need to monitor reboots and unless you have redundant web servers or it's a mail server where downtime is almost OK then yeah. I now wonder about a OTP to enable and disable schg removal. > Tends to hinder proper backup and timely updates. Murphy's law says you're > always going to be on the move when a critical update comes along, which > *will require* a full reboot under your scheme. An offline key was suggested which would mean you could use that machine to do the signing of packages before deploying them. Personally I think it may be useful for interpreter control but as you have said it is no better than immutable in most cases and causes a performance hit that immutable doesn't have.
