[volunteers] [revival] apache dead on svlug, restarting after this dumped state
rick at linuxmafia.com
Fri May 6 04:03:57 PDT 2016
Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):
> If that's so, then please explain why when I point a browser simply at
> <http://lists.svlug.org/>, it happily serves up a PHP file owned by
> _your_ UID.
Beats the hell out of me. I not only never installed PHP software on
lists.svlug.org but would have absolutely no use for it there.
Nor can I recall having had occasion to touch the host's Apache
configuration for any other reason, either.
If some idiot installed PHP on the mailing list host, that really needs
to go away instanter before it hurts us badly. It sure as hell wasn't
> Thank you for leaving it where I was able to grab it and put it on the
> Linode host to serve up Don Marti's...
Um, I didn't 'leave it' anywhere.
> This sounds remarkably like what I _meant_ when I said that kind of
> ChangeLog would be A Good Idea to have, and now you see exactly why.
Um, what you said was a ChangeLog attempting to document _prior_ work on
lists.svlug.org based on console logfiles or something like that. I
could not see any use for that.
You did not respond to my request that you document your work. For the
second time, if you don't mind, please document what you did (including
the few lines of C code) before doing further anything. This would be
your cue to say 'I'll do that soon', or 'I did that today', or something
> However, given that I utterly failed to communicate this effectively,
> as well as this idea to test a replacement for at least one of the
> services, conveying only painful confusion instead, it now occurs to
> me that anything like that that I could write might be less than
> clear, and perhaps some of my recent ChangeLog entries on the Linode
> host might not be very clear, either.
Those looked quite clear to me. (The only thing I did was fix line
Now that you mention it, what really confused me was your idea of
setting up candidate replacements daemons outside the chroot and
_sandboxed_. In the usage I know, sandboxing a process is running it in
a restricted environment, e.g., a chroot or a guest VM, among other
methods. I would not have associated the term 'sandboxed' with 'run on
a different port'.
> I propose duplicating the locations from the Linode host, except
> /usr/local/src, which isn't really intended for site-docs. I propose
> instead /usr/local/share/doc/site-docs.
/usr/local/share is program data files. These are not program data
Look, Daniel, _nowhere_ under /usr/local is 'really intended for
site-docs'. /usr/local/src/[something] is a local convention based on
the Principle of Least Surprise among longtime sysadmins, who would
normally put all completely local non-program files in a subtree of
/usr/local/doc. E.g., in my experience that's where they would look for
And please don't get started again on /srv or any of the other
johnny-come-lately bits of weirdness introduced into FHS to junk it up
after Dan Quinlan ceased being in charge of FHS. Longtime sysadmins
aren't going to look there, either.
So, would you please stop bikeshedding about weird directory choices?
> Python, you say?
> danielg4 at lists:~$ file /var/old-svlug-rfs/var/local/mailman/cgi-bin/listinfo
> /var/old-svlug-rfs/var/local/mailman/cgi-bin/listinfo: setuid, setgid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.0, not stripped
Huh. All the CGIs are ELF binaries, whereas everything in the bin directory
is Python. I forgot the former, probably because the only Mailman binaries I
deal with normally are those in the bin directory. _However_, this
distinction is completely irrelevant to my point, which was that the
httpd must be capable of running CGIs, as opposed to the many small
HTTPds that cannot. Thus, this discussion is wasting our time and
pretty much pointless.
Honestly, Daniel, did we _really_ need to digress onto something utterly
irrelevant to what I was saying? The antecedent discussion hadn't
already chewed up enough time?
Seriously, man, I am getting really, really tired of this.
> Surely you mean both the MTA and SpamAssassin, right?
The MTA and SpamAssassin and Mailman. I wasn't drawing a distinction at
that moment between the MTA and spamd, though of course they are
different but closely linked services.
> By George, I think you've got it! In fact, you might find a curiosity
> in the headers of the last message I sent to the Test list, and I
> could go into its tangential relevance here after you notice it…
Maybe later. I badly need to sleep.
> However, what Sarah installed is Ubuntu Server, where the sanctioned
> MTA is Postfix, not Exim.
WTF? Ubuntu server again? Dammit.
I cannot possibly give a damn less what MTA Canonical, Ltd. 'sanctions'.
Listen, Daniel, I am really tired of arguing every single goddamned
thing, and having to discuss things over and over. If you want to
insist on working out antispam with Postfix, I'm just going to walk away
from administration of lists.svlug.org completely and let you do the
whole goddamned thing your way. And I'll refer all queries and
complaints to you.
I seriously do not think this should proceed further until we get
it over to Debian Jessie 8.0, which prgmr.com also offers prebuilt.
My experience with Ubuntu Server on the Linode host has lead me to not
want to see any more of it, and I have no faith in it as a server
If you disagree, I'm prepared to just wash my hands of this entire mess
and you can run the whole show.
I'm very tired of this discussion. I'd like it the hell out of my life.
More information about the volunteers