[SAC] download server: No space left on device
Martin.Spott at mgras.net
Tue May 15 05:05:51 PDT 2018
Jürgen E. Fischer wrote:
> A reverse proxy wouldn't work - at least not directly - because we upload to
> download and the scripts maintaining the package list also run on download and
> expect files there and the mirrors use rsync.
Why don't you simply do the scripting off-site and just upload the results ?
If this wasn't clear before: We're _not_ talking about a cosmetic issue,
instead, opening the (kernel) NFS server to the entire world is sort of a
major security risk. In times when people are discussing even tighter
restrictions on SSH connections you're introducing RSH-level security.
And, just for the record, my surprise came from realizing that people still
do this on The Internet - in 2018.
Apparently we're driven by different objectives. To me it looks like you're
tolerating even major pain for the sake of offering the complete download
portofolio. But what's your plan when someone takes Osgeo6 down via the
security holes you added ?
That's my concern: Keeping the attack surface as small as possible (BTW, you
only blocked the RPC port on Osgeo6 but didn't care about NFS) in order to
maintain stability. And I might consider joining the group of those who are
in favour of restricting root access on OSGeo infrastructure to only those
people who've proven to understand the security implications of their
> I wonder why you never participated in the "no space left on device" thread
> that started back in 2016 (and even back then this was nothing new), although
> you were mentioned a couple of times as the only one that had privileges to do
> the cleaner and easier solution of just expanding the vm's disk.
I don't remember the details, but a good guess would be that I can't afford
the time to follow more than just a fraction of the list threads. And, BTW,
I could only add disk space if such thing is available, not if all space is
> NFS is just the second "best" solution - but was in reach. And now it's in use
> simply killing it without a replacement disrupts service, which is
> "not-that-great" either - or better put IMHO no option at all.
I'm certainly not going to enter an edit-war on Osgeo6 RPC/NFS
configuration, but I'd like to point out, as explained above, that
disrupting parts (we're talking about a sub-section only !) of the download
service is still a lot better than running an unprotected NFS server on The
Unix _IS_ user friendly - it's just selective about who its friends are !
More information about the Sac