The firewall goes behind the web server not in front of it. Going on the basis that the web server will be compromised at some stage, so only allowing very limited access to other systems will preventing it becoming to toehold in to your private network.
---druck
As I already wrote the thing is in a datacenter and it is on a local network behind an internet router that has no other access between those Raspberries than the outside users have to the network.
Just use USB flash - it's also easier to manage as you can just plug it in your PC to access it. All you need is enough space to keep the kernel and rootfs in system flash, then put /usr on USB.
Theo
That should work until distributions adopt systemd-isms that require /usr to be on the root filesystem. :-(
-- Robert Riches spamtrap42@jacob21819.net (Yes, that is one of my email addresses.)
I think it is time to start the big war against systemd, maybe there should be a VN initiative to start bombing Poettering's house.
/usr has nothing to do with systemd.
-- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzichubg@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML)
Well, "because systemd cannot handle it", /usr/bin was moved to /
Ridiculous.
Get you facts straight.
-- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzichubg@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML)
Get your facts straight.
-- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzichubg@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML)
Useless response. You lose the debate due to lack of *any* facts.
That's what FeeBSD is for.
He is correct, all the ltes move everything to a sinlge partition was exactly because of a programing fart with systemd.
After doing some fairly simply internet searching, it turns out that it's more the other way around: there's an underlying problem that people have been cheerfully ignoring, and systemd just made this underlying problem sufficiently evident and obvious that people are finally doing something about it - and in the process, getting rid of some historical baggage that has long outlasted its original purpose (see for a bit of history).
For instance there's an explanation at :
" You probably discovered this page because your shiny new systemd system referred you here during boot time, when it warned you that booting without /usr pre-mounted wasn't supported anymore. And now you wonder what this all is about. Here's an attempt of an explanation:
One thing in advance: systemd itself is actually completely fine with /usr on a separate file system that is not pre-mounted at boot time. However, the common basic set of OS components of modern Linux machines is not, and has not been in quite some time. And it is unlikely that this is going to be fixed any time soon, or even ever.
Most of the failures you will experience with /usr split off and not pre-mounted in the initramfs are graceful failures: they won't become directly visible, however certain features become unavailable due to these failures. Quite a number of programs these days hook themselves into the early boot process at various stages. A popular way to do this is for example via udev rules. The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices. Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff.
You don't believe us? Well, here's a command line that reveals a few obvious cases of udev rules that will silently fail to work if /usr is split off and not pre-mounted:
egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
-- and you find a lot more if you actually look for it. On my fresh Fedora 15 install that's 23 obvious cases.
[ ... ]/usr on its own filesystem is useful in some custom setups. But instead of expecting the traditional Unix way to (sometimes mindlessly) distributing tools between /usr and /, and require more and more tools to move to /, we now just expect /usr to be pre-mounted from inside the initramfs, to be available before 'init' starts. The duty of the minimal boot system that consisted of /bin, /sbin and /lib on traditional Unix, has been taken over by the initramfs of modern Linux. An initramfs that supports mounting /usr on top of / before it starts 'init', makes all existing setups work properly.
There is no way to reliably bring up a modern system with an empty /usr. There are two alternatives to fix it: move /usr back to the rootfs or use an initramfs which can hide the split-off from the system.
"SUSE Linux summarize some of these points at :
"Booting a Linux system without having /usr mounted (if it lives on a separate file system) is not reliable, as discussed in various threads elsewhere.
Even prior to the implementation of systemd having /usr on a separate file system was an undertaking that was not necessarily for the faint of heart. The fact is that tools that were potentially needed early on in the boot process already live in the /usr tree. The implementation of systemd just forced the issue to the fore front and it then got resolved with the mounting of /usr in the initrd. With this solution having /usr on a separate filesystem now actually works reliably and the separation of /bin, /sbin from /usr/{bin,sbin} is even more artificial than it was previously.
The separation between /usr/{bin,sbin} and /bin, /sbin has historical physical limitation reasons that no longer exist.
Just as we have passed the 64k limitation, and who would ever need more than 64k, we have long passed the physical limitation that made the split of / and /usr necessary, for some background read this .
"// Christian
the third way is to use a minimally populated root /usr and mount a full one over the top.
I remember doing that once years ago, for all the usual reasons. Like /usr being the root of - ahem - users home dirs.
you could boot with no /usr all right, but most of the tools you wanted to use were in /usr/bin..
I fully agree that its all historical and the old layout is pretty much completely inappropriate for modern usage
-- Everything you read in newspapers is absolutely true, except for the rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
FreeBSD ( a true UNIX, not a look a like "Linux" )
The /usr partition
The /usr partition contains a few major sections. There are a few approaches to this section. One is to give it it's own largish partition. Second - and absolutely not recommended - is to lump it into the main / partition (and either move the ports tree or watch its size carefully). Third is to split off several sections either into their own partitions or to symlink them from the / partition to a larger partition. Tuning recomends up to 3Gigs for /usr if you are going to have X installed with source, but I personally feel this would be a little bit limiting. 5-10 gigs seems more reasonable if you have the room.
Try booting to single user on a systemd system that has /usr on a separate partition.
Dzieki, Christian, za post o tresci:
Thanks for doing this research! After being involved with systemd for
4 years, I'm really tired of people spreading misinformation and lies. I have more productive things to do than discussing the same issue over and over again.Once again, thanks for comprehensive explanation. I hope it will help other folks in this thread.
-- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzichubg@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML)
Hm. I don't trust USB flash and why would I want to plug it in a PC? Especially considering it being a router, I can probably access it over the network... I'd expect the package manager to be the only thing to put stuff in /usr or maybe cp for my own stuff sometimes to /usr/local. Besides, would the router still work if /usr disappears?
Then why are you posting here and not busy doing "more productive things"
Like helping Linux, once a usable Unix-compatible system, down the drain by developing crap like pulseaudio and systemd.
It would not be bad when these were developed as alternatives, as has always been the case in opensource development. Create something and see which idiots are going to use it. Abandon it when not many.
However, in this case there appears to be a strong relation with distributors and other development teams to shoehorn the packages into major distributions with no way to get rid of them. So even when you don't want systemd or pulseaudio you are stuck with them, because >100 other packages are "depending" on them. (not really, but in their package descriptions)
I've run USB flash for years - no wearout issues.
Why plug in a PC? Easy snapshots - just clone the USB stick and you've got a bootable filesystem. What to revert to a previous version? Just swap USB sticks. Meanwhile if you have an unbootable NAND/NOR flash on your device you end up messing with serial consoles or worse JTAG to get it back again.
Not unless you design it that way. I'd only pull USB sticks during downtime (once a year or whatever, often when there's some other reason to power down), not on a weekly basis. rsync/whatever backups are in addition to this.
Theo
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.