Anyone else interested in running some of their ARM devices with root mounted read only ?
I like to run devices that are left on 24x7 from read only root.
Recently I had-to revisit the way I do it, but this time I took better notes of what I did, in the hope to make it a less time consuming thing for the future. I've addressed things like:
If there is any interest in this I'll make an article on docs.slackware |
Could be an extension/update to the famous Slackware hardening article.
|
I suppose it has some security implications too (as you can't write until you escalate root privileges to do the remount) ... but my primary objective in running the system RO is making the system 100% power failure proof. Sometimes a power failure may request interactive fsck when the system comes back up again ... that won't happen on a RO system.
|
Even a RW mode NAS would benefit from a ro root IMO?
|
Quote:
On your NAS chances are that at least the volumes that you export will need to be in RW mode hence the NAS might still hang while booting asking for iterative fsck on the exported volumes. You could mark the exported volumes not to get fsck at boot time (in fstab) but then repeated power failures could gradually introduce crap in your inode and block lists to the point where you really start to get bad effects. On a NAS where the exported data is mostly static it's unlikely that you run into inconsistencies in block and inode lists. If your NAS's OS runs off rotating mass storage who cares how mane times blocks get re-writtren you're not going to have the blocks ware out like on flash devices. The most important factor that drove me to running some of my systems with root RO was indeed the flash storage ware. (*) I think the best thing would be to have the NAS (or any other thing that needs to have permanent data saved to RW volumes) under UPS. I see the RO root thing as most useful for things that have basically static data (except for rare occasions where you might briefly remount root RW mode) on flash storage ... thins like access points, routers, firewalls, dhcp servers, print servers and other similar stuff ... or at least that's my opinion. (*): I've some blogs where I do some rambling on flash ware: linux and persistence on live systems running on flash storage some thoughts on unning linux off flash mass storage |
While I generally agree, there are other ways:
The base system could be run RO, while the PAYLOAD could be non-OS managed: After the OS has booted, the rc.local gives control to an dedicated app: 1. sophisticated fsck 2. maybe even basic crc check of data 3. connectivity check and assurance (WiFi, LAN, BT, tty-s etc) 4. data mounted locally and 5. data exported for sharing (nfs,smb/cifs,ftp,tftp,ssh etc) And the rw critical stuff can always be linked to a dedicated var partition on the mass storage (spun or solid) which would be on overlay over an fail-var partition on the OS carrier media (MMC or USB eprom storage) Not to mention fs overlays now that we have live OS "in house" whit Alien BOB's live Slackware? What gives? |
Sorry I should not have digressed ... after all this thread is for finding how many are interested on running their Slackware systems root mounted RO.
Two is not that many :( I might end up just sharing some scripts instead of writing an article about it. |
Well, You didn't:
Both Your post was on topic as well as You didn't post any scripts, either :D ? I surely love to review scripts and snippets! B-] |
Well I suppose that maybe showing the unfinished form that I'm using right now could still be interesting:
What follows is my rc.ro that's called from a slightly modified rc.S and/or used to set things up for the first time. Code:
#!/bin/bash |
I like it, no need to be script-shy :D
now the patches :) |
1 Attachment(s)
I've attached the patch. I forgot to remove an old copy of rc.local from the original rc scripts ... please ignore the rc.local part in the patch.
I use my DDI thing to do network initialization so you might want to also ignore the changes regarding rc.inet* |
Just've read the patch,
You have a pretty neath thingy going on there (random seed o.O ). And I like Your cases on the docu-wiki :thumbsup: |
In the past I've created industrial systems where I've taken steps to minimize writing to the storage device because of the power failure issue and storage wear. So that makes one more interested in your patch.
|
Two is a small number ... but we're a small community so it's a number anyway :D but probably still to small to get Stuart to look into this thingy.
If anyone is going to use the patches I posted above pleas take care that the random seed carried across reboots does not get written do some location on the SD that would make a mess of your file-system in the case your first partition starts before sector 2048 (some of the older fdisk did that). And if you often reboot you might want to deal with id differently as I'm targeting always the same sector .... this is fine for a system that should be running 24x7 but is less then optimal for a system that often reboots. I've not been active in a while on the forum as I've been silently working on a thing I like to call "Geek Watch": an Arduino Nano based watch that can display time in Decimal (for the ungeek), Octal (for the UNIX nerds) and Hexadecimal (for the geek) with a micro cron like alarm system. Definitely off topic but I'm thinking about writing a series of small articles about it starting with how to keep reasonably accurate time without writing crazy compensation functions ... then moving on to a real world button debounceing (where you're not allowed to stop doing everything else while waiting for the button to be released) ... and so on up to intermittent buzzing without writing extra code to toggle buzzer status. |
There is an fairly accurate time source in GPS receivers, FWIW, and they become increasingly smaller and less power demanding?
|
I've recently connected an I2C RTC to one of my Arduino ... it's a real easy and requires very little external components.
When I get some time I'll write an article about it and the maxim's DS1306 is really cheap (60 cents or so) and requires even less power then new gen GPS. You can get really cheap TinyRTC from banggood (I got 5 units for just under 5 Euro) and they came with all the external components soldered and included the 2032 battery. I doubt a GPS based solution could bee that cheap ... but GPS timekeeping will be better then a 60 cent RTC. |
Well the article is kinda 1/2 there already: the DS1307 is a 5V I2C RTC so the voltage level shifting section is exactly the same if you want to connect it to a rPI. If you care to read the DS1307 datasheet it's possible to write a simple shell script to set/read the time on it with the use of I2CTools ... just bare in mind that the registers are in Binary Code Decimal.
Threre is howver a really simple trick to print a 2 digit BCD number as a human readable decimal (print it as if it was Hexadecimal) ... conversion is only required if you want to manipulate the data to set the system clock. Asap I'll add a section to that article with a bit more gory details. |
All times are GMT -5. The time now is 12:11 PM. |