Re: [vox-tech] Test/Upgrade
Quoting Bill Broadley (b...@broadley.org):
> Do you really think lugod's new mail server should be some weird
> conglomoration of upstream source,
> and out of tree patches?
>
> That's batshit insane in my book.
Fortunately, I nowhere suggested that. Not intending to complain, and I
gladly acknoledge that we have the best of intentions in this
conversation and both have a sincere desire to help LUGOD, but this is
the second time consecutively that I've pointed out that Boggis's ideas
in his EximConfig tarball can and should be implemented with packaged
software only and standard sysadmin work on conffiles, etc., for
purposes of integration.
> More details below.
Apologies, good sir, but it's late, I've had a very long day and am
tired, and therefore will merely attempt in all benevolence to cut to te
chase.
Boggis's tarball (and I'll speak from memory, here, so pardon a small
amount of vagueness) is targeted primarily at Debian sysadmins and
provides directions for which Debian binary packages to installto
construct a highly effective MTA + antispam system built around the
exim4-daemon-heavy package, the sa-exim package originally written by
Marc Merlin, the spamassassin package, one or two packages related to
SPF, and optional binary-packaged components that can be included to
carry out greylisting, teergrubing (keeping records in MySQL), and
probably a couple of other optional angles I'm not quite recalling. It
also provides a set of Exim4 conffile snippets that unpack directly into
the /etc/exim4 tree and integrate into the Debian-style many-fragments
configuration structure that Debian package devs seem to like so much
(viz. /etc/apache2/* and all its pieces), where the intent is to ensure
smooth future upgrades of the distro packages (in this case,
exim4-daemon-heavy and sa-exim) without anything breaking, segregating
out local configuration as separate from what is replaced during
upgrade. Likewise provided as working examples are controls exposed
for tweaking all of this. (See tarball contents.)
Part of what is distinctively good about the architecture Boggis
describes with the cited packages as an example is that it does most of
the heavy antispam lifting using MTA rulesets, a working Exim4 set of
which are provided. This is critical to limiting RAM and CPU splurging,
because MTA rules are typically implemented using C code (hence small
and fast), so there's a huge amount of benefit in rejecting 95+% of
arriving spam using MTA rules before handing off the SMTP bitstream to a
ponderous, slow Perl daemon (spamd) to measure the spamicity of the
remaining 5%. Boggis provides some truly clever MTA rules such as te
'callout' ones that test whether the delivering remote MTA is operating
in an RFC-compliant manner _prior_ to accepting the mail with 250
Accept.
The role of sa-exim is also key in Boggis's example, in that Marc
Merlin's code enables (likewise) a consultation by the MTA to spamd to
measure spamicity prior to the MTA deciding whether to say 250 Accept or
550 Die spammer die or 450 Please stick around while I greylist you.
Among several advantages is that this decision-making _during_ the
ongoing SMTP conversation prevents any possibility of creating
backscatter spam.
Now, the working files drop straight into Debian's _exim4_ setup,
whereas many sysadmins would prefer to use Postfix, or Courier-MTA, or
(God help you) qmail. Fine. This doesn't permit the drop-in
functionality the way you can just unpack the stuff Boggis intends for
the /etc/exim4 tree and have it Just Work{tm} effortlessly, _but_ all of
Boggis's excellent ideas are right there to study and implement as you
desire in whatever packaged MTA the sysadmin prefers.
More can be easily learned by having a look at Boggis's documentation
and his tarball. (I will mention once again that the tarball is _not_
a tarball of software, but rather of MTA rules and conffile snippets,
etc.) Or, of course, if readers already think they have the whole thing
covered and have nothing to learn from Boggis and Merlin's work, they
can bag it and do something else.
OK, then?
I'm sorry, and intend no offence, but I'm going to assume (so I can
hurry up and get to sleep) that the above covers what needs to be said,
ergo I'm not going to read the rest of your post at this time. If
there's something significant you think I really ought to read, I would
welcome your telling me so.
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Test/Upgrade
Quoting Timothy D Thatcher (daniel.thatc...@gmail.com): > What happened was that I discovered earlier today that ClamAV had > apparently been misbehaving and had tanked mail/listserv service > entirely, and for a few days, it turned out. I also actually ran an > apt update/upgrade and rebooted the server myself several hours ago, > and indeed it brought the mail server roaring back to life... which is > probably why you've been seeing all those messages suddenly, as it > tries to process through the backlog. Sorry about the blast of > mailer-daemon notices. How/where are you receiving them? > > I'm still getting chunks of mail blasting in, myself, both daemon > notices and junk. I installed clamAV (and spamassassin, too) a while > ago when I was trying to clean up the mail server a bit. I question would the utility and effectiveness of _ClamAV_ in the use-case of the LUGOD MLM/MTA server. I think that's solving the wrong problem. (I realise that you almost certainly inherited the problem.) In the context of a LUG's officers, malware mail isn't a problem because of the malware. It's just funny-looking spam. The problem really is the spam. So, use good antispam. Which brings me to: Architecting effective antispam for a modern mail server is an art form, alas. You can very easily set up an MTA on essentially any Linux distro, but it'll default to basically no spam-rejection at all, and improving on that gets punted to the local administrator. Which sucks. IMO, in architecting from scratch an effective spam defence, and finding the right balance of false negatives vs. false positives, I've found J.P. Boggis's 'EximConfig' tarball and accompanying documentation a good starting place. Unavoidably, it has started to suffer from lack of maintenance, e.g., the software recommended for SPF checking is no longer packaged, so one must do more work than when it was last revised around 2011. http://www.jcdigita.com/eximconfig/ I recommend studying Boggis's tarball & docs irrespective of whether one uses the exact platform he targeted (Exim4 MTA on Debian), because his ideas can be adapted. For the separate problem of 'existing production SMTP host has a terrible spam problem', that's a harder nut to crack without migrating to a better-architected replacement, and you have my sympathies. > We have a pretty severe incoming spam problem, and particularly the > way much of it is getting processed/procmailed out to me and other > officers using gmail and similar services has actually been kind of a > serious problem--and one that is going to need revisiting eventually. Here, you're talking about /etc/aliases-based redirection, right? In other words, root@, sys@, typescript@, @devnull@, if@, demo@, pr@, and webmaster@ ? If so -- frankly -- here in 209, y'all need to give those up. You've noticed, obviously, part of the reason: Those aliases get clobbered as collateral damage in the spam war, and have been increasingly for about a decade and a half. The temptation is to think that you can keep making those feasible if only you make the MTA's spam-rejection really, really exceptional, except that it'll never be quite good enough. The more spam you forward via aliases (either /etc/alias entries or ~/.forward files), the more the receiving MTA perceives your relaying host as a spamhaus, and punishes it, especially receiving domians like gmail.com that do dynamic scoring of spamicity. The other reason: Those aliases inherently fall afould of anti-forgery techniques (SPF, DMARC), and so, depending on the mail's sender domain, are at grave risk of getting either rejected upon redelivery or spamboxed. This cannot realistically be fixed. My current view is that /etc/alias or ~/.forward redirection is now suitable and reliable only for intradomain purposes. The other type of redirection (other than the /etc/alias and ~/.forward one) is of course mailing list managers (MLMs) like Mailman and Sympa. These have the advantages that (1) they rewrite the SMTP envelope, hence can be made to comply with anti-forgery techniques, and (2) they have exactly the substantial built-in intelligent handling and filtering that is missing from the other redirection types. Someone might eventually suggest converting root@, sys@, typescript@, etc. each to its own Mailman mailing list. Don't. The manual administration and hassle required will drive you batty. > I'm up for suggestions on the next move. 1. Cease using /etc/alias entries for cross-domain redirection. (Yes, this is a painful step and an end to a cherished LUGOD tradition.) Instead, list on http://www.lugod.org/contact/ the office-holders' current direct, real, e-mail addresses. 2. Next SMTP host rebuild, spend about a week working on a modern antispam architecture for it, possibly with reference to Boggis's work. Expect it to take real sysadmin work, not just package installation. Sorry to be the bearer of bad news.
[vox-tech] (forw) Re: Linux Computer Infected
Seems to have been intended to be posted, rather than sent just to me in private mail. - Forwarded message from Bob Scofield - Date: Sun, 3 Jun 2018 09:23:47 -0700 From: Bob Scofield To: Rick Moen Subject: Re: [vox-tech] Linux Computer Infected Since Rick expresses skepticism for antivirus companies in this post, I'll use this one to report on my latest discovery. The problem with my computer started after I updated to the latest version of ESET antivirus for Linux. The only thing I had not done to get my re-install finished was to re-install ESET. So this morning I did. And after the install the problem reappeared. Cinnamon and Thunderbird would crash. Firefox was completely unusable. So I uninstalled ESET and now everything is back to normal. Bob On 06/02/2018 11:48 PM, Rick Moen wrote: > Quoting Timothy D Thatcher (daniel.thatc...@gmail.com): > >> Hah, I'm glad it was nothing as nefarious as some weird malware or >> rootkit, or as irritating/potentially expensive as an actual hardware >> failure. Great work, and thanks, Rick. > One more comment (and yes, as can be seen on > http://linuxmafia.com/~rick/faq/ and > http://linuxmafia.com/~rick/lexicon.html#moenslaw-security3, this _is_ > something of a hobbyhorse of mine): > > > _Rootkits_ are by definition NOT attack tools. Period. > > > Yes, the contrary is widely believed, and I know exactly which > commercial interest promotes that and many similar misunderstandings: > It's the security / antimalware industry, which has absolutely no > interest in a well-informed computer user community who understand > security threats. They want a spooked community willing to outsource > and open wallets. > > This essay ended up being long, and isn't yet in proper presentation > format, but I think bountifully illustrates my point about that industry: > http://linuxmafia.com/kb/Essays/security-snake-oil.html > > > Back to rootkits: A rootkit is a set of replacements for regular > administrative monitoring tools (ps, netstat, top, ls, etc.) that have > been gimmicked to ignore the files and processes of an intruder. > The intruder enters a system and escalates to root authority via > OTHER MEANS ENTIRELY, and only then, armed with stolen root authority, > replaces normal system tools with rootkit replacements in order to hide > himself/herself. > > Quoting (myself) from http://linuxmafia.com/~rick/faq/#virus5: > > > [omitting here a very long alphabetical list of 'ringers'; things often > claimed in error to be 'viruses' that simply aren't] > > Every one of those is some sort of _post-attack_ tool; all are > erroneously claimed on sundry anti-virus companies' sites (and > consequently in various news articles) to be "Linux viruses". Some > are actually "rootkits", which are kits of software to hide the > intruder's presence from the system's owner and install "backdoor" > re-entry mechanisms, after the intruder's broken in through other > means entirely. Some are "worms"/"trojans" of the sort that get > launched locally on the invaded system, by the intruder, to probe it > and remote systems for further vulnerabilities. Some are outright > attack tools of the "DDoS" (distributed denial of service) variety, > which overwhelm a remote target with garbage network traffic from all > directions, to render it temporarily non-functional or incommunicado. > > The news reporters and anti-virus companies in question should be > ashamed of themselves: None of the above, in itself, can break into any > remote Linux system. All must be imported manually (or equivalently by > script) and installed by an intruder who has cracked your system by > other means. > > That incompetent reporting sometimes has extremely damaging > consequences: In 2002, British authorities arrested > > (https://www.nytimes.com/2002/09/20/world/computer-virus-author-arrested.html) > the alleged author of the T0rn rootkit, based on their mistaken notion > that it's a "Linux virus". (My efforts to get the Reuters / NY Times > story corrected were ignored, except by cited anti-virus consultant > Graham Cluley, who told me he'd been misquoted.) > > I should mention in passing that feeble albeit genuine malware like the > RST and OSF ELF-infectors are often downloaded and manually installed, > locally, by attackers AFTER THEY'VE ENTERED AND CRACKED ROOT VIA OTHER > MEANS ENTIRELY, often as part of their "rootkits". Some of these help > keep alive UDP-based backdoors to preserve their ongoing access. The > point, again, is that
Re: [vox-tech] Linux Computer Infected
Quoting Timothy D Thatcher (daniel.thatc...@gmail.com): > Hah, I'm glad it was nothing as nefarious as some weird malware or > rootkit, or as irritating/potentially expensive as an actual hardware > failure. Great work, and thanks, Rick. One more comment (and yes, as can be seen on http://linuxmafia.com/~rick/faq/ and http://linuxmafia.com/~rick/lexicon.html#moenslaw-security3, this _is_ something of a hobbyhorse of mine): _Rootkits_ are by definition NOT attack tools. Period. Yes, the contrary is widely believed, and I know exactly which commercial interest promotes that and many similar misunderstandings: It's the security / antimalware industry, which has absolutely no interest in a well-informed computer user community who understand security threats. They want a spooked community willing to outsource and open wallets. This essay ended up being long, and isn't yet in proper presentation format, but I think bountifully illustrates my point about that industry: http://linuxmafia.com/kb/Essays/security-snake-oil.html Back to rootkits: A rootkit is a set of replacements for regular administrative monitoring tools (ps, netstat, top, ls, etc.) that have been gimmicked to ignore the files and processes of an intruder. The intruder enters a system and escalates to root authority via OTHER MEANS ENTIRELY, and only then, armed with stolen root authority, replaces normal system tools with rootkit replacements in order to hide himself/herself. Quoting (myself) from http://linuxmafia.com/~rick/faq/#virus5: [omitting here a very long alphabetical list of 'ringers'; things often claimed in error to be 'viruses' that simply aren't] Every one of those is some sort of _post-attack_ tool; all are erroneously claimed on sundry anti-virus companies' sites (and consequently in various news articles) to be "Linux viruses". Some are actually "rootkits", which are kits of software to hide the intruder's presence from the system's owner and install "backdoor" re-entry mechanisms, after the intruder's broken in through other means entirely. Some are "worms"/"trojans" of the sort that get launched locally on the invaded system, by the intruder, to probe it and remote systems for further vulnerabilities. Some are outright attack tools of the "DDoS" (distributed denial of service) variety, which overwhelm a remote target with garbage network traffic from all directions, to render it temporarily non-functional or incommunicado. The news reporters and anti-virus companies in question should be ashamed of themselves: None of the above, in itself, can break into any remote Linux system. All must be imported manually (or equivalently by script) and installed by an intruder who has cracked your system by other means. That incompetent reporting sometimes has extremely damaging consequences: In 2002, British authorities arrested (https://www.nytimes.com/2002/09/20/world/computer-virus-author-arrested.html) the alleged author of the T0rn rootkit, based on their mistaken notion that it's a "Linux virus". (My efforts to get the Reuters / NY Times story corrected were ignored, except by cited anti-virus consultant Graham Cluley, who told me he'd been misquoted.) I should mention in passing that feeble albeit genuine malware like the RST and OSF ELF-infectors are often downloaded and manually installed, locally, by attackers AFTER THEY'VE ENTERED AND CRACKED ROOT VIA OTHER MEANS ENTIRELY, often as part of their "rootkits". Some of these help keep alive UDP-based backdoors to preserve their ongoing access. The point, again, is that they're an _after-effect_ of break-in, not a method of attack in themselves. It's like a burglar disabling your back-porch door lock from inside your kitchen; it's damage, but not the guy's means of entry. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux Computer Infected
Quoting Bob Scofield (scofi...@omsoft.com): > I've got an infected Linux desktop and I don't have the technical > expertise to fix it. So, I just wanted to explore the notion of 'infected' in general, concerning Linux computers. (In no way is this intended as a criticism of Bob.) It is frequently the case that users say their computers are infected / have malware when all they really know is that something bad is happening on their systems that ought not to happen -- something like a Web browser process immediately terminating upon startup. It's a small leap of logic, but certainly an understandable one. In my first, long post, trying to help advise Bob, I drew a key distinction between system-level problems and user-level ones, e.g., suggesting Bob see if additional user 'test' encountered the same symptom he did under his regular user. Each user has an individual set of configuration files in his/her homedir that, if they get messed up by... anything (user mishap, 'malware' processes the system gets tricked into running with regular user authority, damage caused by bugs in installed user software run with regular user authority, etc.)..., the user's software experience can get sabotaged _without_ there having been any damage to the system as a whole. And the reason that's a really key difference is that you as a non-privileged user deliberately are not wielding the ability to mess up, edit, add to, delete from, etc., files in any of the many trees that are _system_ trees. Which also means that even the most devilishly nasty malware imaginable, if you happened to run it as 'you' (run it with your user authority), can do only the damage that you, yourself, could have done. That is why, in a real sense, _provided_ you are not finding dumb ways to run Linux malware with elevated privilege, and provided it isn't left running for a long time to chip away at your system and find unfixed local security problems to 'escalate privilege' with, such Linux malware is precisely as big a danger to your system as you are, and as big a danger to your personal files as you are. (The corrolary to this is that the biggest danger by far to any Linux server is a sysadmin wielding root authority, something even scarier than a programmer clutching a screwdriver. ;-> ) And I actually need to 'fess up to a bit of tunnel vision I suffered in making the above-described distinction between system-level problems and user-level ones: I almost totally forgot -- but sort of added near the end -- that something like a critical RAM shortage in effect manifests as _both_ a system-level and user-level problem. But often I forget that new Linux 'desktop' users are seldom taught that just about the first things you need to do is: o Check memory using 'free' or similar. o Check disk space using 'df' or similar. o Check process list (using 'ps' or similar) looking for funny business. That is so ingrained in old-school Unix teaching that sometimes it's difficult to remember that newcomers may not think to do that, and almost certainly aren't familiar with the tools. Which is a pity. ...and, please note, Bob's problem immediately became obvious when he checked the third of those three basics. Rod's point that it _could_ have been a hardware problem was also an excellent one, but IMO one wants to look for the low-hanging fruit, first. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux Computer Infected
Quoting Timothy D Thatcher (daniel.thatc...@gmail.com): > Hah, I'm glad it was nothing as nefarious as some weird malware or > rootkit, or as irritating/potentially expensive as an actual hardware > failure. Great work, and thanks, Rick. Just one more thing about that: http://linuxmafia.com/~rick/lexicon.html#moenslaw-security3 Moen's Third Law of Security "Malware is _not_ a security problem; malware is a secondary _after-effect_ of a security problem." People who focus on particular exploits against particular vulnerabilities (or worse, software packages like "anti-virus software" that do so) have already lost the security battle, because they aren't focusing on what's important -- which is correcting their own strategic errors that make those recurring vulnerabilities possible (and inevitable). Marcus Ranum described what is important perfectly, in his essay "What Sun Tsu Would Say" (http://www.ranum.com/security/computer_security/editorials/master-tzu/): o Run software that does not suck. o Absolutely minimize Internet-facing services. If you have to keep chasing after holes in the same hopelessly bad software (PHP, WordPress, AWstats, wu-ftpd, lpd, etc.) — or, worse, paper over that underlying cause with anti-malware software — then you're addressing the _wrong problem_. The computer-security advice Ranum attributes to Sun Tzu bears repeating, too: If you are fighting a losing battle, it is likely one of three things: a) You are continuing a trend in a losing war -- and therefore should not be surprised. b) You have chosen to fight the wrong battle. c) You are stupid. (I'll hasten to say that I'm not calling anyone stupid. Ranum, a major security expert from the BSD community, putting words in Sun Tzu's mouth, is saying that certain people _might_ be stupid. Personally, I'd only go so far as to say 'misguided'. ;-> ) The examples cited of wu-ftp, lpd, and AWstats now seem obscure, but please do remember that I created the page a long time ago. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux Computer Infected
Quoting Bob Scofield (scofi...@omsoft.com):
> I've got it fixed. But first thanks to Brian, Tim, Rod, and Rick.
Congratulations, Bob! Good work.
When you're feeling in a mood to geek out and get to know some
old-school Unix command-line tools, here are some related to memory and
processes:
top
'top' is a bit more instantly likeable than the others, because it
defaults to auto-refreshing its display of resources used by individual
processes every second (which is usualy handy), _and_ it has a couple of
operating modes.
In the default mode, it displays processes in order of CPU usage, with
the biggest CPU-grunt hogging processes on top. But then, if you press
'M' (capital m), then the tool flips to its alternate mode, showing
processes in order of _RAM_ usage, biggest RAM-hogs first. This is where
things start, unfortunately, to get complex and eye-crossing, because
the sort key used is '%MEM". But there are several other columns with
other details of memory usage, which I'll not detail here. Suffice to
say each can be significant, depending.
(Irony alert: For a command-line tool, 'top' is a bit
resource-intensive all but itself. On more than one occasion, a Unix
server, slow and somewhat unresponsive because of running low on RAM,
has been driven into falling over because 2 or 3 sysadmins ssh'd in and
simultaneously ran 'top'. ;-> )
free -m
The 'free' command is a system-wide report (not a process-level report)
on the current state of memory usage. The 'm' switch I added means
'...and please report values in units of megabytes, for
human-friendliness'. There are a bunch of details in free's output
about usage of both physical RAM and virtual RAM, which you just have to
learn how to correctly interpret -- not difficult, but you'll end up
looking at the man page.
ps auxw
The 'ps' command reports process status (thus the abbreviation), and
I've added parameters, detailing which would add too much gory detail,
that have the effect of making ps report all currently running processes
without restriction. The resulting output is guaranted to be verbose in
both width and length, so one usually ends up piping it to 'less' or to
a filter to extract only what you want to know about.
As with 'top', the ps command defaults to showing many columns about
processes, and there are actually more that can be dredged out with
other formatting directives (to ps) if necessary. If it seems excessive
and overwhelming at first, be advised that's an entirely normal
reaction.
Leaving RAM aside for a moment, it's also important to be able to check
on disk usage. The 'df' command is vital for a view of disk usage at
the level of entire filesystems (partitions). 'df -h' will show you
human-friendly (what the 'h' is for) output numbers.
Equally important is 'du', which once you master its options is
incredibly handy to show disk usage of subdirectories or other sets of
files.
Last in that department, let me offer the following handy Perl script
that you can write to your system (using root authority) as
/usr/local/bin/largest20 . Don't forget to also make it executable by
doing (as the root user) 'chmod u+x /usr/local/bin/largest20'.)
--
#!/usr/bin/perl -w
# You can alternatively just do:
# find . -xdev -type f -print0 | xargs -r0 ls -l | sort -rn -k +5 | head -20
# Sometimes also handy: du -cks * | sort -rn
use File::Find;
@ARGV = $ENV{ PWD } unless @ARGV;
find ( sub { $size{ $File::Find::name } = -s if -f; }, @ARGV );
@sorted = sort { $size{ $b } <=> $size{ $a } } keys %size;
splice @sorted, 20 if @sorted > 20;
printf "%10d %s\n", $size{$_}, $_ for @sorted
--
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux Computer Infected
Quoting Rod Roark (r...@sunsetsystems.com): > Sounds more like a hardware problem. Open it up and vacuum out the > dust, especially from the CPU fan. Then run a memory test (probably > available at the boot screen). Definitely could be. One way to test this hypothesis is by booting and using a desktop system from a live-CD (by which I include live systems on USB flash drives, etc.) Linux distro, as has been suggested separately. If the problem reproduces using that entirely separate bootable system, that strongly points towards a hardware problem. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Linux Computer Infected
Quoting Bob Scofield (scofi...@omsoft.com): > I've got an infected Linux desktop and I don't have the technical > expertise to fix it. FYI, nothing you said in either of your posts would suggest malware. (Also, IMO: http://linuxmafia.com/~rick/faq/#virus) Your system has a Linux Mint installation with the Cinnamon (variant-GNOME3) Desktop Environment. Suggestion #1 (move .mozilla out of the way): > When I clicked on the link to the story or video or whatever it is, > Firefox crashed. It crashed permanently. If I try to start > Firefox all I get is the "Mozilla Crash Report." I've removed > Firefox 3 times. I've purged Firefox twice. I've reinstalled and > the problem persists. Am betting this is related to your per-user configuration files for Firefox. Try this (it's reversible): 1. Make sure Firefox is _truly_ not running. To do this, first, open a terminal console. (I'm very much not a GNOME person, so you find and do that based on your local knowledge.) In the following, the '$' stands for a non-root user's shell prompt. '#', used in a later bit of this message stands for the root user's shell prompt. Therefore, the suggestion is that you type the commands quoted below, but not the prompt characters. (This is a display convention you will encounter widely in discussion of Unix system operations.) Now: $ ps auxw | grep firefox If an instance of Firefox is running, you need to kill the process. Like: $ killall firefox $ killall -9 firefox (or whatever the process's name is) Now: 2. $ cd $ mv .mozilla .mozilla-save $ exit 3. Try starting Firefox again. Don't get alarmed that your bookmarks, etc., aren't there. The information for them is safely ensconced in the .mozilla-save directory. 4. Report back to the mailing list. Does Firefox still go kablooey, even with a fresh-generated .mozilla tree that resulted when you restarted Firefox in step #3? Let us know. 5. After shutting down Firefox, put your .mozilla directory back: $ cd $ rm -rf .mozilla $ mv .mozilla-save .mozilla $ exit You are back. Suggestion #2 (add user 'test'): See if a second user set up for test purposes encounters the same problem or not. If yes, then you have a system-wide problem. If no, then you have a problem isolated to your personal login's configuration files. Make sense? Open a terminal console, and: $ sudo su - # adduser test # passwd test # exit $ You have just created additional local login user 'test' and assigned that new user a login password. The 'passwd' command will, FYI, have prompted you to type in that password twice, to ensure that you haven't fumblefingered it. Now, do whatever it is you do to shut down the Cinnamon DE, logout, and return to the Linux Mint grapical login thingie. This time, instead of logging in as your regular user, login as 'test'. _If_, as I suspect, you have no system-wide problem but rather a problem isolated to your personal login's configuration files, then you in the guise of the 'test' user will now enjoy a pristine Cinnamon DE environment with no weird 'crashes', etc., etc. One last thing: I mean no personal criticism here whatosever, but I'm going to make a guess based on long decades working with Linux newcomers that if I asked you to check and make sure your system isn't running short on RAM because some process or processes is/are grabbing it, you would say 'How?' Right? Your symptoms might easily be caused by runaway RAM consumption by something. There are ways to track that down using old-school Unix command-line tools like 'free', 'ps', and 'top', but how to interpret their information requires learning. Additionally, intelligently interpreting that information would require learning what the various running processes are and what they're doing. Any GNOME variant has a great many running processes, IMO, making that part of the task more difficult than it would be with more-lightweight environments. But anyway, try the 'test' user, and report back whether the problem replicates with that user or not. I'm going to bet 'no'. Based on your answer, this mailing list's denizens will be in a better position to give you meaningful and useful, i.e., targeted, suggestions. (I didn't cover how to remove user 'test', but it's also not difficult. But frankly I'd advise keeping that login around.) > In the meantime I tried to read the story with Chromium. Chromium > now constantly crashes. It will not stay up for more than about 30 > seconds. Could be that something's hogging RAM. > What's more, Cinnamon (I'm using Linux Mint) is now crashing every > once and awhile and I've never seen Cinnamon crash before. Could be that something's hogging RAM. (If the best solution is for someone to drive over and debug this for you, coolness, but unfortunately I personally am way too far away, down at the south end of San Mateo County.) ___
Re: [vox-tech] My wife's website
Quoting Richard S. Crawford (rich...@underpope.com): > I found the offending code, buried deep in the actual database. The code > has been eliminated, and all passwords have been changed. > > Whack-a-mole. Congratulations. Now, the harder question beckons: How did it get there? ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] My wife's website
Quoting Alex Mandel (tech_...@wildintellect.com): > I outsource to Wordpress.com, just pay the $15 a year to use a custom > domain. I figure if the main vendor behind the software can't keep it > patched and safe, no one can. Quoting from Marcus Ranum's[1] 'The Six Dumbest Ideas in Computer Security', http://www.ranum.com/security/computer_security/editorials/dumb/ : #3) Penetrate and Patch There's an old saying, "You cannot make a silk purse out of a sow's ear." It's pretty much true, unless you wind up using so much silk to patch the sow's ear that eventually the sow's ear is completely replaced with silk. Unfortunately, when buggy software is fixed it is almost always fixed through the addition of new code, rather than the removal of old bits of sow's ear. "Penetrate and Patch" is a dumb idea best expressed in the BASIC programming language: 10 GOSUB LOOK_FOR_HOLES 20 IF HOLE_FOUND = FALSE THEN GOTO 50 30 GOSUB FIX_HOLE 40 GOTO 10 50 GOSUB CONGRATULATE_SELF 60 GOSUB GET_HACKED_EVENTUALLY_ANYWAY 70 GOTO 10 In other words, you attack your firewall/software/website/whatever from the outside, identify a flaw in it, fix the flaw, and then go back to looking. One of my programmer buddies refers to this process as "turd polishing" because, as he says, it doesn't make your code any less smelly in the long run but management might enjoy its improved, shiny, appearance in the short term. In other words, the problem with "Penetrate and Patch" is not that it makes your code/implementation/system better by design, rather it merely makes it toughened by trial and error. Richard Feynman's "Personal Observations on the Reliability of the Space Shuttle" used to be required reading for the software engineers that I hired. It contains some profound thoughts on expectation of reliability and how it is achieved in complex systems. In a nutshell its meaning to programmers is: "Unless your system was supposed to be hackable then it shouldn't be hackable." "Penetrate and Patch" crops up all over the place, and is the primary dumb idea behind the current fad (which has been going on for about 10 years) of vulnerability disclosure and patch updates. The premise of the "vulnerability researchers" is that they are helping the community by finding holes in software and getting them fixed before the hackers find them and exploit them. The premise of the vendors is that they are doing the right thing by pushing out patches to fix the bugs before the hackers and worm-writers can act upon them. Both parties, in this scenario, are being dumb because if the vendors were writing code that had been designed to be secure and reliable then vulnerability discovery would be a tedious and unrewarding game, indeed! [...] Your WordPress has never been _safe_, merely because it got patched. And patched. And patched. And patched. As Ranum points out, if the past security work had been sufficient, it wouldn't have been necessary to subsequently keep fixing the same code modules' security breakdowns in the same places over and over -- the sure mark of fundamentally bad code that never gets actually fixed. IMO, the only appropriate remedy for fundamentally bad code (like public-facing PHP itself, not to mention WordPress) is to cease using it. A few years ago, after repeated PHP security problems, I banished all public-facing PHP from my linuxmafia.com site by converting all pages that relied on it to any of several means of serving static HTML, instead. This turned out to be a good thing from several perspectives, including the discovery that several site features never needed to be assembled dynamically by a PHP interpreter at page load time in the first place, but were implemented that way solely because of coder (including my own) laziness. > The other route to go, is to switch to a static site generator > https://www.fullstackpython.com/static-site-generator.html > Many of which are blog oriented. Word. I certainly include myself in the 'coder laziness' category, e.g., my personal FAQ pages had been designed by yr. humble servant as a series of PHP include directives (for the header, footer, table of contents, etc.) for no better reason than that being easier than thinking. Five minutes' pondering yielded the obvious alternative of building the pages using GNU make. http://linuxmafia.com/~rick/faq/ http://linuxmafia.com/~rick/faq/Makefile Other pages such as BALE (http://linuxmafia.com/bale/) turned out to be easily generated using PHP interpreter /usr/bin/php5 locally in periodic cron jobs to generate static HTML pages, i.e., they never needed to be dynamic, just periodically generated. So, with a modest bit of rethinking and revisiting implementation approaches, I got better security, better performance, better reliability. Pretty good deal. [1] Noted BSD security
Re: [vox-tech] My wife's website
Quoting Richard S. Crawford (rich...@underpope.com): > That's what I was afraid of. Unfortunately I can't find the malware itself. https://codex.wordpress.org/FAQ_My_site_was_hacked http://www.wpbeginner.com/beginners-guide/beginners-step-step-guide-fixing-hacked-wordpress-site/ https://sucuri.net/guides/how-to-clean-hacked-wordpress And I'll bet your wife doesn't have the ability to do a clean restore from backup, does she? That would be among the very first things to fix, IMO. Personally, I find public-facing PHP and developed apps requiring it generally to be security-problematic and best avoided. But people do seem to love their WordPress anyway, which is why an entire hosting market niche has evolved around outsourcing WordPress security headaches to commercial outfits that charge a premium for compensating for the basic error or electing WordPress (WPengine, Bluehost, Dreamhost, Siteground, Cyon, Flywheel, Kinsta, Pantheon, 34sp.com, LiquidWeb, Mshini, SoHosted, TVC.net, Interserver, Pagely, GreenGeeks, Raidboxes, Savvii, RoseHosting, et alii). Problem: The software is ridiculously overbaroque, making debugging difficult, and is an ongoing security nightmare. Solution: Expect customers to spend hundreds of dollars a year extra on specialised security-mitigation services. It's a natural! ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Need Partitioning Advice
Quoting Bob Scofield (scofi...@omsoft.com): > How important is it to have a separate partition for /tmp? I've > got 2G on the desktop I'm using right now. The partition for / is > 15G. I vaguely recall a discussion here years ago and people > saying that /tmp is on a separate partition to prevent / from being > crowded. Eh, 'crowded' as in hitting 100% capacity? There is some small logic to that. But you haven't considered a vital distinction. SSD or hard disk? Some new laptops have one, some the other. The wear characteristics of SSD have improved greatly since early days, but in general you still want to do what you can to avoid excess wear. A /tmp filesystem is by nature pretty write-intensive. One can make an argument that a host with only SSD storage should have no swap filesystem. Then, if it runs out of free RAQ, the kernel OOM (out of memory) process killer will just terminate things as necessary, rather than swapping them out. > Does it make sense to have a 2G /tmp? Consider: If you're considering a laptop with a 2TB hard drive, why _not_ have a 2GZB /tmp filesystem? SSDs are really a radically different (and almost entirely better) proposition, and ideally you should consider carefully how to proceed with them. See for example https://wiki.debian.org/SSDOptimization . On a system with a single hard drive, I pay close attention to filesystem _ordering_ to minimise average seek distance, which means grouping the most-accessed filesystems on either side of the swap filesystem, and the less-accessed filesystems further out from the middle. If the system has mulitple hard drives (that aren't in a RAID set), then additional optimisations are possible. And some attention to filesystem mount options is useful for several reasons. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Floppy drive with Linux Mint LMDE 2 MATE
Quoting Bill Kendrick (n...@sonic.net): > Ironically, floppies made longer ago seem to last longer. > Floppies (mostly 3.5") seem to have been made more cheaply / lest robust. Part of it is: Greater data density was achieved through use of finer magnetic particles. Those inherently are more likely to demagnetise neighbouring particles over time, the price of higher density. E.g., you will probably find that your 720 kB 3.5" floppies, if you have any, have lasted better than the 1.44 MB ones. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] any OTR preferences?
Quoting Bill Broadley (b...@broadley.org): > Ha, looking at your link and found: > Because the download integrity for all of these packages is abysmal Yes, I was intending to point out that bit to you in particular, but couldn't find it on the November 16th blog post -- but I see it's on the April 2nd original blog post of which the November one is a refresh. I notice the refresh article is using keytool instead of sha256sum to verify the Signal app key's fingerprint, FWIW, not that that does anything for the basic, larger problem. > Would be nice to have copperhead OS, then something automated like: > * launch container/sandbox without rw to /system > * use google play to download APKs and verify signatures. > * save downloaded APK to /tmp > * shutdown container > * have copperhead install and verify the APKs (after checking they won't > overwrite copperhead APKs) > > That way no google play services, and no way for google to change any > copperhead > files. Yes, concur. For _me_, I don't compelling need for anything from Google Play, but I realise I'm a mutant. > For most installing signal via: > Download the apk. > Unzip the apk with unzip org.thoughtcrime.securesms.apk > Verify that the signing key is the official key with keytool -printcert -file > META-INF/CERT.RSA > You should see a line with SHA256: > 29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0 > EA:FB:A2:DA:35:AF:35:C1:64:16:FC:44:62:76:BA:26 > Make sure that fingerprint matches (the space was added for formatting). > Verify that the contents of that APK are properly signed by that cert with: > jarsigner -verify org.thoughtcrime.securesms.apk. You should see jar verified > printed out. > > Is *WAY* too complicated. As they point out, this results from the Signal people and the F-Droid people fighting over acceptance criteria. You'll note that the author says in the notes 'Wow, the Signal vs F-Droid issue is a stupid hot mess. Can't we all just get along and share the software? Don't make me sing the RMS song, people... I'll do it...' ;-> Still 'n' all, yeah, Copperhead OS and drills like the one on the Tor blog post(s) are as good as we have, at the moment. What boggled me was what a near-total showstopper the baseband CPU/firmware problem continues to be. The article's April iteration (https://blog.torproject.org/blog/mission-impossible-hardening-android-security-and-privacy) goes through some elaborate steps to deal with this and related problems. (At present, they recommend decoupling the phone or tablet from baseband problems by using a separate MiFi device.) Personally, the only Android-type device I have is a Nook Tablet running Cyangenmod, which at least sidesteps the baseband problem. Copperhead OS would have been much better but, as the Tor blog notes, so far, Copperhead doesn't support any wifi-only devices, only certain smartphones. I have my doubts about progress. The OEMs still are failing to support meaningful service lives for their hardware, and everyone's trying to use tricks to control customers. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] any OTR preferences?
Hey, Bill (Broadley), I wonder if you've seen this useful page from the Tor folks about doing the best one can with Android security: https://blog.torproject.org/blog/mission-improbable-hardening-android-security-and-privacy -- Cheers,"It's easier to act your way into a new way of thinking Rick Moen than think your way into a new way of acting." r...@linuxmafia.com-- Jerry Sternin McQ! (4x80) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Change to vox-tech list moderation
Quoting Bill Kendrick (n...@sonic.net):
> My problem was that the subject lines were all the same: a generic
> message telling me something got auto-discarded.
Just to be clear, I wasn't referring to the '(n) messages were
discarded' advisories.
In the model where non-subscriber postings get held and expire out, the
listadmin gets a daily summary of main headers of all held messages,
which is _usually_ enough information to spot quickly any held non-spam.
What I was saying is that, in the event of uncertainty about that
judgement, if you _also_ receive an immediate notice on each message
being held, then even if a non-spam expired out of the queue before you
could approve it, you as listadmin can retrieve the full message from
the immediate-notice advisory message and re-send it manually.
I find this a workable routine, especially with a 3-day hold duration.
Obviously, Views Differ{tm}. ;->
IMO, if the spam is too onerous even with intelligent management of the
Mailman queues, then it means you aren't doing good enough
spam-rejection inside the receiving MTA, and should concentrate on
improving _that_.
Linux MTAs have totally inadquate default antispam defences on (to my
knowledge) all Linux distributions. I would guess this has been one of
the biggest motivators driving the ongoing flight away from people
operating their own MTAs and onto outsourced webmail (e.g., GMail,
Fastmail, and competitors). Being stubborn, I went the other way: 'Ah,
needs better early-SMTP antispam', and tightened things up.
Again, absolutely not being critical of other people finding different
solutions. Being caught in the middle of the spam war is a difficult
situation, and mailing list managers, being SMTP forwarders, are
inherently caught in the crossfire more than other systems are.
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Change to vox-tech list moderation
Quoting Bill Kendrick (n...@sonic.net): > Well, this wasn't clearing of Mailman's queue, but of my inbox. > (Technically, a mailbox that slurps up all of the mailman administrative > noise, via a good ol' procmail filter) I do sympathise. Personally, I've gotten really quick at quick-scanning and deleting (usually) the Mailman held-message notices a couple of times a day that accumulate in mbox ~/inboxes/lists . A few seconds and I'm done -- even though I listadmin a whole bunch of Mailman lists for a half-dozen-ish domains. But I wasn't being critical, just pointing out something sometimes missed. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Change to vox-tech list moderation
Quoting Bill Kendrick (n...@sonic.net):
> I did not bother having posts held ("HOLD" option, vs "DISCARD"), since it
> was a very rare occurrence. These days, since the mailing list volume is
> extremely low (but the spammers still try sending messages to the list
> address), almost ALL discarded messages are junk, and it's kind of mind
> numbing and tedious (and a waste of my time) to have to go through them,
> _just in case_ someone posted from a bad address.
A different approach is to let the held spam expire out. On General
Options, item 'Discard held messages older than this number of days. Use
0 for no automatic discarding' has a Mailman-default value of 0, i.e.,
hold forever -- which I consider crazy. Typically, I set that to '3' so
I'm likely to catch held non-spam even over a three-day holiday weekend.
As I also get notices of individual held spams ('Should the list
moderators get immediate notice of new requests, as well as daily
notices about collected ones?' on General Options set to 'yes' instead
of 'no'), even _if_ I accidentally let a non-spam expire out of queue
and realise that on (say) day 4, I still have the full message text and
can bounce it to the list then.
I mention all of the above because I keep finding Mailman admins doing
'mind numbing and tedious' manual clearing of queues, unaware that
automatic expiry would do this work for them without any of that hassle.
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Quoting Dr. Larry Ozeran (loze...@clinicalinformatics.com): > Thanks Rick. > > This is why I have such great respect for the members of this list. > You have such valuable experiences that you are willing to share. I > regret that I have had the experience of server issues occurring at > bad times (right after talking about our product at a trade event), > but thus far none have been PHP or MySQL related, so I very much > appreciate the insights of others. Looking over my notes about tightening PHP security (direct link http://linuxmafia.com/faq/Security/php.html), I see something I might consider writing more about (in that piece): I talk about several prototype files Debian provided for /etc/php5/apache2/php.ini , specifically: /usr/share/doc/php5-common/examples/php.ini-paranoid /usr/share/doc/php5-common/examples/php.ini-recommended The thing is, the distribution-provided /etc/php5/apache2/php.ini file stated in header comment lines... well, let me just quote it: ;;; ; About this file ; ;;; ; PHP comes packaged with two INI files. One that is recommended to be used ; in production environments and one that is recommended to be used in ; development environments. ; php.ini-production contains settings which hold security, performance and ; best practices at its core. But please be aware, these settings may break ; compatibility with older or less security conscience applications. We ; recommending using the production ini in production and testing environments. ; php.ini-development is very similar to its production variant, except it's ; much more verbose when it comes to errors. We recommending using the ; development version only in development environments as errors shown to ; application users can inadvertently leak otherwise secure information. So, thing is, I could swear that the _default_ php.ini Debian installed to /etc/php5/apache2/php.ini was the _development_ variant -- because when I got around to looking through it and locking it down, I was a bit shocked at the high default security exposure. It was exactly as I was working through that file, commenting out dangerous and unneeded optional interpreter features, that I wrote my modest hardening guide (more as notes for my own benefit than with any intent to publish). That experience was one of my first signs that something was not right with PHP and its security posture. It might be my imagination, but I think part of what's happening is that only lip service is normally given to enabling only the language functionality actually necessary; that many developers of PHP developed applications blithely expect deploying sites to have the kitchen-sink set of language functions available and their code mysteriously fails if you don't. So, deploying sites are passively led into bad habits and bad defaults. And, for example, picture a world where the developers gravitate towards php.ini-development and sysadmins towards php.ini-production. What's going to happen as a natural tendency? You know developers; they'll happily use the features in front of them, which then will ratchet up the need for those in deployment. Not good. It's a bad sign when the development default environment includes bad security and the attitude is 'be unsafe only while developing code and we'll fix it all up later'. A brief clarification: The incursion that happened just as I got on an ocean cruise this past February happened _despite_ all the security tightening, on account of yet another grave flaw in the core mod_php code. (I cannot tell you which flaw because I elected to just disable the thing rather than work further on it.) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Quoting Dr. Larry Ozeran (loze...@clinicalinformatics.com): > Rick, thanks again for your insights. You are most welcome. > You are, of course, correct that we would not redesign our software > without a significant and deep assessment of benefits and costs > (money, time, resources, etc.). Most of the PHP, MySQL, and related > code has been developed in house. I probably coded 10-15% myself. > The intent of my comment was simply to indicate that we do not > blindly accept that there is no better option than what we are > doing. If there are strong arguments to support considering making a > switch, I would not exclude that possibility without reviewing the > pros and cons simply because we have a large legacy investment. I > consider your response (below) to fall into the 'cons' (to > switching) category and will definitely compare your PHP security > recommendations against what we currently are and are not doing. I am very glad to be of help -- and certainly was trying to be at pains to avoid advising anyone to merely redesign, especially without knowledge of the particulars. My own disaffection with PHP was markedly increased when I boarded a cruise ship with my wife from San Francisco to Sydney, and right on the day of my departure my logcheck reports started indicating a serious attempt to break security on my server via (what turned out to be) mod_php -- exactly at a time when I had just boarded an ocean vessel with only satellite Internet at very high prices. Somehow with a painfully thin straw of ssh bandwidth and only one hour of high-latency, low-reliability Internet access each evening, I was able to kludge together a lockout of the kiddies within a couple of days and before they were able to compile an exploit kit. When I reached Sydney, one of the first things I did from my hotel room was rip out the last bits of public-facing PHP exposure so I'd never have to worry about that again. My _own_ view is that PHP is entirely too much like the scenario Marcus Ranum described in his rather caustic 'What Sun Tsu Would Say' essay, i.e., as Ranum phrases it, 'If patching hasn't been working, why are we still doing it?' I stopped needing to apply the PHP patch du jour by no longer exposing it to public networks. But whatever works for you is of course great. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Quoting Dr. Larry Ozeran (loze...@clinicalinformatics.com): > Since we are serving data that can change every few minutes, we > can't move to static pages. Since we are providing that data to > users from multiple originating sources, we pretty much have to be > internet-facing. We have put security procedures in place, but I > know that security is more an ongoing process than an endpoint and > there is always more that will need to be done. If there is a better > way to meet the needs of users other than MySQL+PHP, I am always > open to new ideas. Meaning no criticism, I notice in looking upthread (http://lists.lugod.org/pipermail/vox-tech/2016-May/017013.html) that you mention only that your use-case involves PHP-served pages, but not what drives that particular choice of software. Sometimes, a local site uses PHP because it runs developed software resting on the PHP interpreter, e.g. Wordpress, MediaWiki, etc. Other times, that choice resulted from 'Data for each page must be pulled on a per-visit basis from MySQL, therefore some HTTP-invoked process must do a SQL query and assemble page contents and we happened to use PHP to do that because our Web guy knew how to do that.' And I'm sure there are other scenarios -- but dynamic is not synomyous with PHP in any event. Irrespective of how you arrived at that choice, obviously you would not lightly decide to rearchitect. A number of guides to tigthening PHP security to reduce risk exist and may be useful. My own modest effort, last updated when PHP5 was new, is here: 'PHP Security' on http://linuxmafia.com/kb/Web/ . ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Quoting Bill Broadley (b...@broadley.org): > >Does anyone know any downsides to using the webtatic PHP packages on > >CentOS 6? > > I've seen many machines with ugly configurations related to cpanel, > custom php installs (sometimes more than one), and fragile very hard > to reproduce apache configurations. > > Although I guess I shouldn't complain, they get hacked and I get consulting. (Sadly, this won't answer Dr. Ozeran's question, either:) I've lately come to the conclusion, from many years as a Linux server admin, that PHP is tolerable on a Unix machine _provided_ it isn't ever exposed to public networks, because the ongoing security nightmare is otherwise not justifiable. I mean, yes if management is paying you to do it and the money's good, but if you're the boss, say 'Hell no.' So, e.g., every Web page on my linuxmafia.com server that used to be dymanically assembled by the PHP interpreter at Apache page-load time are (more recently) instead built on-disk in advance using automake or a cron script. Fortunately, none of those pages needed to _actually_ be dynamic; it was just coder laziness that chose that implementation. For example, the coder who helped me convert BALE (http://linuxmafia.com/bale/) from its original mid-1990s static HTML incarnation to PHP + MySQL set it up so every page load assembles the page anew, from several PHP fragments plus the results of a MySQL query (furnishing the events rows). When I realised the underlying reality of this being static data changing only once on the 1st of each month, I converted it into a static HTML page generated by a cron job in /etc/cron.monthly/ , and then Apache serves up just that static file. Whole huge categories of security threat have completely away for good, when I ditched runtime PHP. If I had any Web applications that actually relied on the PHP interpreter at load time, I'd try really hard to ditch them. It really is IMO that bad. And I say that because, so to speak, Ranum is my guru: http://www.ranum.com/security/computer_security/editorials/master-tzu/ That having been said: Dr. Ozeran, I know of nothing against the Webtatic repo's PHP packages. It seems like a competent external repo for CentOS/RHEL, though I have no relevant experience. Hope that helps! ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] perl rename
Quoting Mark's tech help (markinda...@hush.com): > I'm a tad baffled by the usage of perl here. Some part of a learning > exercise for perl, or could one not just come up with a line of bash > commands.. a combination of mv and sed with a pipe &/or redirect? I think this is yet another case, among countless others, where the very first response to querent needed to be some gentle form of 'What problem are you actually trying to solve?' P.S.: $ man 1 mmv MMV(1) NAME mmv - move/copy/append/link multiple files by wildcard patterns SYNOPSIS mmv [-m|x|r|c|o|a|l|s] [-h] [-d|p] [-g|t] [-v|n] [--] [from to] DESCRIPTION Mmv moves (or copies, appends, or links, as specified) each source file matching a from pattern to the target name specified by the to pattern. This multiple action is performed safely, i.e. without any unexpected deletion of files due to collisions of target names with existing file- names or with other target names. Furthermore, before doing anything, mmv attempts to detect any errors that would result from the entire set of actions specified and gives the user the choice of either proceeding by avoiding the offending parts or aborting. mmv does support large files (LFS) but it does *NOT* support sparse files (i.e. it explodes them). [...] ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] perl rename
Quoting Mark's tech help (markinda...@hush.com): > Reason: I'm running my usual, minimalist distro! (Busybox does too > many things on this.) You.. you lucky, decked-out full-installation > people, you! But really, mmv looks great-- will have to install it. > Thanks for the tip. Yr. welcome. mmv is one of numerous ways of filling the functionality-hole that newcomers to Unix from MS-DOS inevitably found perplexing (back in the day). The difference lies in the way arguments get processed. Unix shells expand globs before passing the arguments off to the called executables. The MS-DOS COMMAND.COM shell did not. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Email
Quoting Richard Harke (paleopeng...@gmail.com): Thanks for all the suggestions. I wasn't able to get the import function in thunderbird to work. What I finally did is: open thunderbird and create the folders (empty, of course) Then I exited thunderbird and, one folder at a time, I deleted the folder (directory) and then re-created it using a python program that converted a maildir to mbox. Next time I opened thunderbird my emails were there. Glad that worked. You'll note that my bottom line was, in fact: My own inclination would be to attack the problem directly and convert the Maildir tree to mbox using a utility for that purpose. So, yeah. ;- When you placed your script-constructed mbox files in Thunderbird's mail directory tree and restarted Thunderbird, it noticed them and automatically created binary index files for them, which you'll now find in those same directories. And that is actually the very approach I did for a long time, just by experimenting pretty much the way you did. I heard about the Import/Export extension thing only later, and gather that it merely makes the process you used a bit more GUIfied and user-friendly. Thunderbird's pretty nice -- and extensible. Nowhere near as fast and bulletproof as mutt, but that's a high goal to match. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Email
Quoting Susan Baur (su...@cdl.edu): Hi Richard, Did you see this stackoverflow article? http://stackoverflow.com/questions/4780441/how-to-import-mails-into-thunderbird-from-maildir-format Despite the URL and title, the question posed (and I'll get to the two answers in a moment) involve figuring out how to get mails down from a local IMAP server (something like Dovecot). The local IMAPd is said to have _its_ message store in Maildir. Answer #1 was: Use a local mail reader to bulk-pull all mail from the local IMAPd and save the mail from the local mail reader, e.g., to mbox format. Then use that mbox with Thunderbird. (The helper was a bit vague about how to do the latter part.) Or, helper #1 adds, move the entire Maildir tree to the machine where Thunderbird will be running, install Dovecot as a local IMAPd on said machine with the Maildir tree as _its_ message store, and configure Thunderbird to take its mail from the local IMAPd. Answer 1a was a bit baroque, but suited the situation where the user had a local IMAPd. But Richard doesn't have one of those. Answer 1b is even a bit more baroque, but in present context not only assumes Richard has a local IMAPd but also will want to keep using one. Answer #2 was: Install the Import Export Tool extension for Thunderbird (that I've mentioned before). Rename all individual mails in the Maildir trees to have .eml filename extensions (using utility mmv) and then use the Import Export Tool extension's feature to 'Import all EML files from a directory'. This would work, if Richard has the mmv utility. I admire answer #2; it's ingenious. Lots of ways to solve the problem, and this one exhibited lateral thinking. My own inclination would be to attack the problem directly and convert the Maildir tree to mbox using a utiltiy for that purpose. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Email
Quoting Richard Harke (paleopeng...@gmail.com): The kmail versions are 4.14.2 on my old machine and 4.14.1 on my new macine. I'm not entirely sure of what format mail files they use but I looked at a few of the files and those appeared to contain a single email message each. So I guess that is maildir format. If those individual files are inside a triplet of sibling subdirectories 'cur', 'new', and 'tmp', then that is indeed Maildir. There are many utilities that will convert Maildir to Thunderbird's exact variant of mbox (one called 'mboxrd', technically). One from Python's 'mailbox' library is covered here: http://stackoverflow.com/questions/2501182/convert-maildir-to-mbox ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Email
Quoting Richard Harke (paleopeng...@gmail.com): Rod's link included the suggestion to make the conversion on the old machine which I'm going to try as kmail is still working there. It's good that KMail is still working there, but you will need to consider what you're going to _do_ with KMail and its message store files. The page Rod cited (a good page that, FYI, gives a lot of the same advice I've given you, including the recommendation of using Thunderbird's Import/Export Tools extension, and addresses quite a lot of other situations, besides) is necessarily a bit vague about KMail -- because different versions of KMail have, as I said, used diverse message store file formats. (The page says Kmail uses a compatible version of the mboxrd flavour of mbox, which is true, but it also has used other data store formats over time.) The version you were using might have used mbox file format, which would have been convenient, but also might have used something else. Irrespective of the file format, KMail can doubtless _export_ to mbox format, which would also be useful. You'd have gotten a more exact answer sooner if you'd revealed what file format your version of KMail used -- or at least the version number of KMail. You've not provided either. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Email
Quoting Rod Roark (r...@sunsetsystems.com): I liked the efficiency and small footprint of Claws, but keep coming back to Thunderbird (Icedove in Debian) as having the features I need to work with my clients and the least amount of bugs that get in my way. I made Thunderbird (Icedove) work well in a corporate (MS-Exchange!) environment recently. Slow compared to mutt, but nonetheless a winner IMO. (I used DavMail as a gateway.) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Email
Quoting Richard Harke (paleopeng...@gmail.com): I did install Thunderbird (icedove) but I'm stuck ay impoting my existing emails. I created a folder to match one from kmailm planning to import one folder at a time. I believe you mistyped 'Ah, thank you for calling attention to my omitting any coherent details of what format my old email is currently in. It's trapped inside whatever datastore KMail [you supply version] uses.' (Hint, hint.) One issue is that KMail used a number of storage formats over time, sometimes offering a couple as options. Here is an article that describes a user of KMail 2.x (from KDE 4.7.2) getting out of KMail to Thunderbird with his mail intact: http://www.ulduzsoft.com/2012/01/from-kmail-to-thunderbird/ (Author 'George' doesn't like the default mbox format used by Thunderbird, so configures Thunderbird to use Maildir instead.) One obvious workaround irrespective of KMail's storage format -- usable _if_ KMail is working well enough to sync to remote mail servers -- would be to sync KMail's local folders to a remote IMAP server, and then IMAP-sync that same mail downwards (the other direction) into Thunderbird. For extra credit and vastly greater speed, do this via an IMAP daemon (such as Dovecot) and MTA (such as Exim/Postfix) that you run locally on you Linux host. But that might be more setup than you care to take on. Tip: On general grounds, you'll want this extension for Thunderbird: https://addons.mozilla.org/en-US/thunderbird/addon/importexporttools/ It makes bulk-importing of mbox-formatted mail files more human-friendly than without the extension. The extension does not, however, natively understand any other file formats (e.g., Maildir). ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Email
Quoting Richard Harke (paleopeng...@gmail.com):
Does any one do email anymore (as opposed to webmail) ?
http://linuxmafia.com/~rick/faq/?page=misc#outlook
I have used kmail for years but now it is badly broken.
I'm guessing you have a preferance for very featureful graphical mail
clients (MUAs = Mail User Agents). Here is a page cataloging all known
MUAs for Linux, grouped by category (graphical vs. console, open source
vs. proprietary). I last updated it two years ago, so of course it
doubtless is no longer 100% complete and correct.
The most useful thing about it, for you, would be the
pointer-highlighted entries indicating which are the most-popular
programs. I recommend sticking to the first section: 'graphical, open
source'.
'MUAs' on http://linuxmafia.com/kb/Mail
Have a look at Claws Mail as your first candidate. Sylpheed and
Thunderbird also have many fans.
Your problem report of 'can't seem to make a folder to import my old
email' is what an old boss of mine used to call 'almost useful', i.e.,
it's completely useless as stated for anyone wanting to help you,
because it utterly fails to give any idea of what format your 'old email'
is currently in. You might, for example, mean that your mail is
trapped in KDE4's 'Akonadi' storage service as invoked by KMail. But
you didn't clarify that point (yet).
Should I try evolution
{shudder} Of course, as Mr. Lincoln said, it's the sort of thing that
will be enjoyed by those who enjoy that sort of thing. ;-
(I have a prejudice against huge, slow, overly complex software, but you
may not feel the same way. Evolution is sort of a poster child for the
qualities I personally do not like in software. So is KMail.)
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Hosting a email server at home but port 25 is blocked, what do I do?
Quoting James Nessen (ness...@jimsoffice.org): I would go the VPS route. Super easy to do and most offerings today will fit within your budget. I have used both DigitalOcean and Linode (currently with Linode). The cheapest VPS on DigitalOcean is 5.00 per month and gives you 512mb of ram (which isn't much), and the cheapest plan on Linode is 10.00 for 1GB of ram. Have you checked http://prgmr.com/ ? I haven't looked lately, but it used to be very price-competitive. Small VPS outfit in Silicon Valley, caters specifically to technical people who are not going to need handholding. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] some people can't send to list
Quoting Bill Kendrick (n...@sonic.net): Here ya go! First of all, really good job! It's legible, clear, and nothing stands out immediately as 'should be fixed.' Looks like an exemplary professional job. I'm used to seeing ones that make my eyeballs ache and the ghost of Jon Postel weep. ;- Unpacking my 'If one is being picky' criteria, hmmm Three things total. o Already mentioned the RFC2182 section 5 suggestion of min. 3 nameservers. 604800 ; Expire o RFC1912 suggests an Expire value between 1209600 (14 days) and 2419200 (28 days). Unless you have an unusual reason to make cached zones expire in only 7 days, you might want to at least double zone life. (I tend to be old-school and express all time values in seconds, too, but an argument can be made that using zonefile macros for minutes, hours, days, weeks improves legibility. I'd be a hypocrite if I dinged anyone for eschewing that syntactic-sugar improvement, because I haven't started using it, either. ;- ) o No glue records in the parent .COM zone for the two authoritative nameservers, with the result that both are 'stealth nameservers'. The consequence of having stealth nameservers is that the situation can be confusing and can cause delays or other hard to diagnose inconsistencies. Basically, there should be NS lines with corresponding A records _within_ the nameserver records of the .COM domain (called 'glue records') for ns1.domaindiscover.com and ns2.domaindiscover.com. This isn't LUGOD's fault. Tierra.net d/b/a Domaindiscover has its glue records slightly fux0red. (I remember this. They've been doing this for a long time. I used to have my domains registered there, and liked them, but never used their nameserers.) Here are .com's own nameservers: $ dig -t ns com. +short e.gtld-servers.net. g.gtld-servers.net. k.gtld-servers.net. c.gtld-servers.net. j.gtld-servers.net. i.gtld-servers.net. h.gtld-servers.net. a.gtld-servers.net. l.gtld-servers.net. d.gtld-servers.net. m.gtld-servers.net. f.gtld-servers.net. b.gtld-servers.net. $ Let's ask the first of them about ns1.domaindiscover.com: $ dig -t ns ns1.domaindiscover.com @e.gtld-servers.net. ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34213 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; AUTHORITY SECTION: domaindiscover.com. 172800 IN NS ns1.tierra.net. domaindiscover.com. 172800 IN NS ns2.tierra.net. ;; ADDITIONAL SECTION: ns1.tierra.net. 172800 IN A 216.104.162.2 ns2.tierra.net. 172800 IN A 216.104.163.2 $ So, you see, the parent .com zone completely lacks NS and matching A records for ns1.domaindiscover.com. ns2 is likewise, so I'll not waste space showing that. If you want, you can fix this problem by changing your auth nameserver references in both your domain registrar record and inline in your own zonefile, to use ns1.tierra.net and ns2.tierra.net instead of ns1.domaindiscover.com and ns2.domaindiscover.com. Anyone want to help us with this? :) Someone(s) with ongoing LUGOD involvement would be best. Please talk to me offlist if you can't find same. Anyway, truly excellent zonefile. The only half-serious issue is the one your registrar imposed on you, and that's doing very well. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] some people can't send to list
Quoting Alex Mandel (tech_...@wildintellect.com): If you're seeing this on the list then I think it's fixed. To make sure I'm clear: I'm volunteering to look through the entire zonefile and make polite suggestions (no obligation) as to anything LUGOD might choose to improve. I've done a lot of DNS profesionally for a long time, FWIW. -- Cheers, I'm ashamed at how often I use a thesaurus. I mean bashful. Rick Moen Embarrassed! Wait--humiliated. Repentant. Chagrined! Sh*t! r...@linuxmafia.com-- @cinemasins McQ! (4x80) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] some people can't send to list
Quoting Bill Kendrick (n...@sonic.net): Brian came over, I did the song dance to gain access to the account at domaindiscover aka tierra.net, and we fiddled with things. How's it looking now? Would you consider posting the new zonefile so it can be seen in its entirety? Understandably, the authoritative nameservers don't permit random members of the public to pull those down. $ dig -t axfr lugod.org @NS1.TIERRA.NET ; Transfer failed. $ dig -t axfr lugod.org @NS2.TIERRA.NET ; Transfer failed. $ One fine point: RFC 2182's recommendation is minimum three, maximum seven authoritative nameservers. Two is disrecommended as too thin. The choice of two only might be dictated by your chosen hosting provider, which doesn't make this error any smarter, but does make it more difficult to overcome. (Shortchanging redundancy is sadly common among ISPs.) Personally, I use mutual nameservice with other technical people -- and I do follow my own advice, too: $ whois linuxmafia.com | grep '^Name Server: ' | wc -l 5 $ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] some people can't send to list
Quoting Nick Schmalenberger (n...@schmalenberger.us): Yeah, but honestly why is it a problem anyway? Sure it allows creating DNS loops and other weird stuff, but it can also be useful (like a lot of things that can make loops). Be sure to use numerous long chains of symlinks in your filesystems, too, and report back in a few years. Hey, what harm can a bunch of indirect reference do? ;- -- Cheers, Atque memento, nulli adsunt Romanorum Rick Moen qui locutionem tuam corrigant. r...@linuxmafia.com McQ! (4x80) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Systemd thoughts?
Quoting Nick Schmalenberger (n...@schmalenberger.us): Wow man, nice job hijacking a thread to spout close minded insults about an upcoming talk that is explicitly meant to show why its not as bad as people say it is. Yes, Mark, that was a little uncool. Entirely new threads are best _not_ started as replies to existing ones. It's better for a new thread to be, y'know, new. Eschewing the systemd init[1] on distros where it's become default is a very minor technical problem that is pretty easily solved. E.g., I apt-get upgraded a test system to Debian 8.0 Jessie (current Testing branch, soon to be Stable), and was able to revert the silent changover to systemd, and prevent its future return, like this: # apt-get install sysvinit-core sysvinit sysvinit-utils # apt-get remove --purge --auto-remove systemd # echo -e 'Package: systemd\nPin: origin \nPin-Priority: -1' /etc/apt/preferences.d/systemd I'm actually looking forward to testing OpenRC[2] on this test system, a well-made event-driven init utterly without the scope-creep drawbacks that created notorious flamewars several years ago, and that some LUGs are only belatedly noticing. Other distros such as Fedora and OpenSUSE that no longer provide any other properly packaged inits will be a problem, but there are plenty of alternative distro choices. Personally, I'm really looking forward to hearing this talk and I don't usually make it to LUGOD more than once a year. I respect Alison Chaiken immensely, and was of course pleased to invite her to give this talk at SVLUG, and would not have dreamed of speaking up to challenge any part of it, given that I was the meeting host. Listen carefully for the numerous highly doubtful points, like the bit where she does a comparison based on number of lines of code of a binary. [1] It should not be forgotten that systemd is much more than just an init, providing a large suite covering many functions. [2] https://lwn.net/Articles/512719/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] some people can't send to list
Quoting Brian E. Lavender (br...@brie.com): Hey, so word is that some can't send email to the lugod lists because the mailserver the MX record is a CNAME rather than an A record? That is known to be a common problem. I hear there are a number of MTAs that refuse to deliver to RFC-noncompliant sites. People relatively new to maintaining DNS zonefiles tend to drastically overuse CNAMEs, I notice. My own recommendation is to _never_ use a CNAME for any use-case in which an A record will do the job -- because an 'A' record will never get you into trouble in exactly the situations where a CNAME can (MX and NS records), and because overuse of CNAMEs tends over time to create a tangle of indirect reference. That tangle can then lead to further problems, like removing an 'A' record but forgetting to hunt down and repoint the CNAMEs resolving to it. There is exactly one use-case that actually requires a CNAME: pointer to an 'A' record in a different DNS zone. I personally use them for that function _only_, and nowhere else. Some readers may be thinking 'But the advantage of my CNAMEs is that I only need to update an IP in one place. Using A records instead, I'll have to update the same IP in lots of places.' Correct -- but smart people use sed (or equivalent). Which means it's the same action to update an IP in hundreds of lines as on one line. Avoiding CNAMEs where such are not necessary also eliminates multiple DNS lookups. In that sense, unnecessary CNAMEs are like unnecesary symlinks. -- This message falsely claims to have been scanned for viruses with F-Secure Anti-Virus for Microsoft Exchange and to have been found clean. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Cannot install Ubuntu alongside Windows 7
Quoting Thomas Johnston (trjohns...@ucdavis.edu): I primarily use Linux for my personal endeavors; however, there situations/applications for my work where I am forced to use Windows. And although I could run Windows in a virtual environment, I don't know how well that would work when I need to remote desktop into my office computer. https://en.wikipedia.org/wiki/FreeRDP https://en.wikipedia.org/wiki/Rdesktop (optional front-ends include the 'Remmina' GNOME/gtk+/xfce4 thing) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] recommended partition scheme for a dual boot windows 7/ubuntu machine?
Note: I will not be addressing the specific use case the original
poster had in mind of a dual-boot workstation -- and instead detail
a Linux server scheme. Personally, I think virtual machine solutions
(VirtualBox, VMWare) are almost always far better than dual booting, and
I would urge considering those.
Partition strategy in general is a repeatedly re-argued discussion on
vox-tech. The deceased equine was last flogged June 2009, methinks.
People merely looking to justify the simplest possible partition layout
should carefully avoid reading further. ;-
Quoting Rod Roark (r...@sunsetsystems.com):
I try to avoid creating a partition without a good reason.
Some good reasons (that of course are context-dependent):
http://linuxmafia.com/~karsten/Linux/FAQs/partition.html
(Karsten updated and generally dusted the page since the 2009 iteration
of this discussion.)
I would add (for the specific context of my current server host):
o Grouping of filesystems to minimise average HD seek distance
(a concern that happily vanishes completely if you switch to SSD,
as I will be doing soon)
o The use of custom fileystem types and mounting options to achieve
particular per-filesystem administration and performance goals.
In the server /etc/fstab file below, '/boot' is of course vestigial: I
wouldn't include it in a current build. Current host has three physical
hard drives: boot drive sda and mirror pair sdb/sdc ('md' RAID1 set).
# file system mount point type options dump pass
proc/proc procnosuid,noexec,nodev 0 0
none/syssysfs nosuid,noexec,nodev 0 0
tmpfs /runtmpfs defaults 0 0
devtmpfs/devdevtmpfs mode=0755,nosuid0 0
none/dev/ptsdevpts mode=6220 0
none/dev/shmtmpfs defaults0 0
#
/dev/sda7 / ext3defaults,errors=remount-ro 0 1
/dev/sda1 /boot ext2defaults0 2
/dev/md3/home ext3nefaults0 2
/dev/sda8 /recovery ext3noauto 0 2
/dev/sda9 /usrext2nodev,ro0 2
/dev/md4/usr/local ext3defaults0 2
/dev/sda6 /varext2noatime,nodev,nosuid 0 2
/dev/md1/var/libext3nodev 0 2
/dev/md2/var/spool ext3defaults0 2
/dev/md0/var/wwwext3nodev,nosuid0 2
/dev/sda5 noneswapsw pri=20 0
/dev/sdb8 noneswapsw pri=10 0
/dev/sdc8 noneswapsw pri=10 0
(Note absence of UUID noise.)
Note groupings to minimise disk seeking, which is by far the slowest
operation a hard disk does. Such grouping, to the extent successful,
should also reduce wear and extend drive life (less thrashing).
sda ordering:
sda1 /boot
sda5 swap
sda6 /var
sad7 /
sda8 /recovery
sda9 /usr
sdb/sdc mirror pair ordering:
md0 /var/www
md1 /var/lib
md2 /var/spool
sdb8/sdc8 swap
md3 /home
md4 /usr/local
For each spindle, I've grouped text to the swap partition the subtrees
that take the biggest beating (most frequent disk access) on a server
system.
/usr is kept normally read-only as a measure to partially protect it
against the system's biggest enemy: the sysadmin, and his clumsy
thumbs, especially before morning coffee. There's an apt hook to
remount the fileystem temporarily rw for package operations and then
remount it ro afterwards. This is also a small last defence against
the dumber types of trojans.
Similar remarks apply to the nodev,nosuid flags. If a subtree should
never have SUID files or device files, then making them not valid there
is A Good Thing.
Having /var (other than /var/spool and /var/lib) ext2 rather than ext3,
and with the noatime mount option, makes its write performance a
significantly better. (relatime is often good, especially on SSDs,
depending as usual on context.)
Many 2013 improvements are not present in the above, e.g., tmpfs, and
the layout resulted from an emergency rushed rebuild in 2008 following
destruction of my old server in a lightning storm. There's probably
a small list of other enhancements that would be made in a modern build,
and SSDs make many past tweaks obsolete. And ext4 / btrfs weren't on
the table back then.
The new hardware will be 100% SSD-based and thus different and simpler.
(No more concern about seek distances.) I'll proably lean conservative
and go ext4 -- except for /var, which will probably still be ext2 with
noatime, as that's difficult to beat for performance and cuts SSD wear.
Probably no swap at all.
Things I need to look into:
o Any complications with making sure an all-RAID1 disk array's
Re: [vox-tech] Possible rootkit
Quoting Peter Salzman (p...@dirac.org):
Nice catch, Rod!
Boy, though... what an unfortunately named process!
Because no rootkit would ever try to hide itself, right? ;-
{sigh} So much misinformation.
http://linuxmafia.com/pipermail/sf-lug/2012q4/009651.html
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Possible rootkit
Just seeing what insights might be gleaned from this. Quoting Richard Harke (paleopeng...@gmail.com): I may have screwed up. I opened a GIF that I received in an email using ImageMagick. This implies that you were doing so as your regular userID, not as root or any other privileged user. The image didn't have a close button so I used ps -A to find the task. I didn't find any called ImageMagick but there was one named display.im6 and when I killed it, the icon on the task bar went away. So, first thing to consider is: 'What is ImageMagick?' http://www.imagemagick.org/ says: ImageMagick® is a software suite to create, edit, compose, or convert bitmap images. The key word to notice there is 'suite'. It's not a single program called 'ImageMagick' (or anything else). It is a collection of utilities (and, as it turns out, a programming interface for other frontends to transparently use those utilties and their related libs). As mentioned on http://www.imagemagick.org/script/command-line-tools.php, ones of ImageMagick's approximately dozen command-line tools is one called 'display'. That appears to be what you observed in your ps output. But I also found a task called rtkit-daemon which I killed. As you'll have seen from the discussion thread, this process is benign -- to the extent that any of the bloated, horrific, and constrantly changing betaware emerging from the Freedesktop.org people is benign. ;- It's the Realtime Policy and Watchdog Daemon, a D-Bus system service that changes the scheduling policy of user processes/threads upon request, permitting the user to impose real-time scheduling on normal user processes. We could have a whole separate discussion about whether friends let friends us Freedesktop.org system software (including GNOME3, D-Bus, Polkit, etc.). However, for whatever reason, your system does include such (ugh) system components. On the one hand, it's commendable of you to experiment and find out what processes you actually want to run through the straightforward and logical expedient of killing them and seeing if anything you care about breaks. On the other hand, in my experience, the noble goal of knowing what processes you run and running only the processes you want to run becomes so extremely difficult with the most-complex Desktop Environments (such as GNOME3) that the effort will soon become impractical (unless you switch to simpler DE software or to no DE and using just an old-school window manager). But now I also find a whole new directory named /run which seems to have a lot of executables in it. https://wiki.debian.org/ReleaseGoals/RunDirectory /run is a new cross-distribution location for the storage of transient state files -- that is, files containing run-time information that may or may not need to be written early in the boot process and which does not require preserving across reboots. /run is a tmpfs. /run replaces several existing locations described in the Filesystem Hierarchy Standard: /var/run - /run /var/lock - /run/lock /dev/shm - /run/shm [currently only Debian plans to do this] /tmp - /run/tmp [optional; currently only Debian plans to offer this] /run also replaces some other locations that have been used for transient files: /lib/init/rw - /run /dev/.* - /run/* /dev/shm/* - /run/* writable files under /etc - /run/* In any case I assume everything in /run is trojaned. Nope. Actually, if you look at /run, you'll notice that it's a root-owned hierarchy. So, if we take as given your assumption that the gif that you handed to the ImageMagick 'display' utility was a devilishly clever misshaped file crafted to convince /usr/bin/display to do evil things, how would that hypnotised utility escalate privilege to root authority in order to make modifications in /run? I am open for advice. Best advice I can think of: Your concern and interest in knowing what's a legitimate system process is commendable. Rather than being embarrassed over the false alarm, consider building on the experience to deepen your knowledge of your system, which is in the final analysis the only effective way to distinguish legitimate from illegitimate system operation. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] inject false information into dns
Quoting Bill Broadley (b...@broadley.org): What you said. * Authoritative only servers don't cache Well, yeah, authoritative-ONLY servers would have no use for caching by definition, as they aren't accepting data from elsewhere. DNSSEC is definitely quite worthwhile. I just am mostly wary of people treating it as if it were magic crypto sauce and the solution to Internet site authentication and key managment -- when attention to a few fundamentals elsewhere gets you a lot further. * DNS based Amplification attacks are a major issue these days A lot of this results directly from the widespread reliance on open recursive servers. So, Don't Do That, Then -- thus my polite disagreement with Tony on that key point. The more I've pondered this problem space, the more attractive 'split split' DNS (where authoritative and recursive service are completely decoupled) seems. http://www.ida.liu.se/~TDDC03/literature/dnscache.pdf https://www.sans.org/reading-room/whitepapers/dns/current-issues-dns-32988 If nothing else, having a highly protected recursive-only server that's as local as possible is a really good idea. I like having a localhost-only recursive server, actually, e.g., on laptops -- the last word in 'can't flood _this_ with spoofed responses'. SSH prevents this by using public keys to exchange a secret key, which is used for that session. However, the keypair (and passphrase) can be stolen on the usage end if that host has been compromised, and this is how public-key SSH credentials get stolen and abused all the time. Example: http://linuxmafia.com/faq/Security/breakin-without-remote-vulnerability.html The firm where this happened, which I didn't care to identify at the time, was VA Linux Systems, which was h4x0red by a kiddie in South Lake Tahoe who'd compromised a university shared computer, used that host to collect outgoing public-key SSH credentials a developer used to ssh into shell.sourceforge.net, escalated to root on that shared host and installed trojaned /usr/bin/ssh there, then last collected the public-key credentials of a VA Linux Systems IT Dept. employee (not me!) who made the error of then sshing or scping inbound into corporate servers from the shared Sourceforge host. * DNSSEC can protect against local ISP Just to clarify: If you use the 'forwarders' keyword in BIND9 to offload traffic to the ISP recursive server, the DNSSEC capabilities of your local nameserver are going to be undermined. Even BIND10 is not yet aimining to fully validate forwarding: http://www.isc.org/blogs/dns-forwarders/ So, Tony, that's yet another reason not to keep using your forwarding scheme. Additionally even if the government did do that, you could immediately notice the change in signing key and if you knew me you could enquire why such a change happened. This is key point, and bringing the 'temper-evident' quality back into HTTPS is one of my _other_ current measures, as see below: Similar applies to SSL certificates. If you are worried about secure communications with someone you can store their public key. While a government can publish a new public key, they can't magically produce the missing private key. So even the NSA has to be careful, faking a public key on any kinda of wide scale is lightly to draw significant attention. Word. And one step towards making SSL tamper-evident (on the Web) is to change Web browsers' happy-go-lucky default of saying absolutely nothing about changes in SSL certs or their CA attestations as long as they continue to be attested by some CA or other that's in the browser's keyring. Those keyrings have proven to be a joke. Even the Turkish government has been able to use a captive CA to promulgate forgeries. One tool for alerting browser users to cert or attestation changes is Firefox extension CertWatch (Certificate Watch). It's not very clever; it just tells you when an SSL cert or its attestation has changed since last encounter, leaving entirely up to you how to interpret that change and what to do about it. That is not a comprehensive solution, but I find knowing about the fact of a change a great deal better than not knowing. For my own self-signed Web site SSL cert, I carry around its hash value in my PDA for comparison, same as with my SSH host and personal keys. Sadly certificate authorities are anything but trustworthy. So I prefer the ssh model. There are some projects to build an alternative to the laughably broken CA attestation scheme. http://web.monkeysphere.info/ http://convergence.io/ * Pick good passwords, never use them for more than one site/service, preferably generated by a machine. I susggest an open source password database like keepass (It works on windows, linux, android, and IOS). I consider an online password safe program suboptimal because it is exposed to attack and compromise if your machine is -- albeit it's hugely better than no password safe at all. My own chosen
Re: [vox-tech] inject false information into dns
Quoting Tony Cratz (cr...@hematite.com): This prevents hackers from injecting false information (aka DNS cache 'poisoning'), in an attempt to re-direct people trying to access a real website to a fake, phishing or criminal site. I will attempt to answer you question by giving a very high level overview. I do ask others (Rick, Alex and any other person who knows DNS) to keep me correct if (when) I say something wrong, if if they feel I left something out which needs to be covered. Thanks for your thoughtful run-through. It makes me feel like a bad penny breezing in and doing drive-by comments: Apologies for not having the time to write a more-careful and considered rejoinder. Paul Vixie (and others) decided we needed a better method and developed Bind which used the Domain Name System instead of bang-paths. FWIW (and not any kind of criticism, just historical trivia), there was an overlapping step where first ARPANET and then the InterNIC at SRI International maintained a central HOSTS.TXT file (per RFC 953) that could be fetched from a standard location via ftp. Of late, Ubuntu has gone one more step, they have set-up what is called a 'caching name server' when you use DHCP. Have they? Good. OTOH, it's always been trivial to set up a local nameserver for better performance, reliability, and security. The term 'caching name server' is one I would avoid using in favour of clearer alternatives that are more specific and meaningful. (Again, I mean no criticism of your fine explanation, but wish to bring additional clarity to the subject.) 1. _All_ DNS servers of various and sundry sorts do caching -- so saying that a nameserver is a 'caching name server' really doesn't tell you much. 2. Far more meaningful is whether the nameserver does authoritative service or not. (By 'authoritative' service, I mean serves up information of its own, as opposed to querying, caching, and providing DNS data sourced from elsewhere.) The other type of DNS service -- serving up and caching data queried from elsewhere -- is somewhat loosely called recursive service. Complicating the nomenclature somewhat is the fact that a DNS server's query to another DNS server can either have the 'recursion desired' (RD) bit or not. The query thus characterised (RD bit set vs RD bit unset) is called either a recursive query or an iterative query. Those queries are treated differently by the receiving nameserver. Last, there is the issue of forwarding, to which you alluded. A few DNS server packages (dproxy, Dnsmasq) have essentially no local DNS-resolution intelligence of their own and are capable _only_ of forwarding to a more-capable nameserver any queries local processes + hosts submit to them. (As you said, BIND9 can be configured to forward elsewhere queries whose answers it doesn't have in cache. It differs from dproxy and Dnsmasq in having a considerable amount of local DNS-resolving intelligence that can be used if you wish to do so.) As these nuances are a bit complex and a bit counter-intuitive, I long ago wrote a (metaphorical) 'networking fairy tale' about the mythical Village of Lan to illustrate them: http://linuxmafia.com/~rick/lan.html Also, I have classified and summarised all DNS software for Linux according to what sort of service it does: http://linuxmafia.com/faq/Network_Other/dns-servers.html If you run your own name service (BIND-9), depending on how you set it up you can still use your ISP as a 'forwarder'. This means, instead of doing a recursive search up to the TLD and then down to the DNS server for the domain we just ask the ISP if they have the domain in their cache (and most of the major sites will be already in the cache). By using 'forwarders' you can save a lot of time by not having to do the full search. I beg your indulgence for my polite difference of opinion. (I have the discussion often.) As background: Specifying forwarders tells BIND9 to not use its independent ability to resolve DNS questions whose answers aren't already in the local cache (aside for records for which it's authoritative), but rather to offload all uncached queries to one or more remote nameserver (with the RD bit set) and have those do the work. The belief that this 'saves a lot of time' rests on the undeniable fact that ISP nameservers tend to run with a bountiful cache set. Thus, initially the ISP nameserver has an advantage on account of the loaded cache. However, over a quite short period of time, your local cache fills quite beautifully with or without a forwarders line, so any initial advantage evaporates almost entirely within minutes. But then the longer-term consideration becomes of interest: ISP nameservers (even those of good and praiseworthy ISPs) are a very serious security and performance / reliability weak spot. The security problem arises even from
Re: [vox-tech] replace running kernel with new one
Quoting Tony Cratz (cr...@hematite.com): Before my friend Hugh Daniels passed away he mention there was a way to fork/exec/chain a new kernel to replace the current running kernel. Due to his passing, I never did learn how. ksplice. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] replace running kernel with new one
Quoting Tony Cratz (cr...@hematite.com): ksplice. At first glance this did not really help. But on one of the pages I found what I was looking for. Kexec is the command I wanted. ksplice and kexec are both ways to replace one running kernel with another running kernel without a full reboot and with continuous uptime. ksplice is older and has now been emborged by Oracle, Inc. -- which, come to think of it, may have inspired the development of kexec as an alternative approach. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] apt-get -f install fails to work
Quoting Hai Yi (yihai2...@gmail.com): thanks but nope, tried those 3 commands - it didn't work. I strongly recommend quoting the entire relevant portion of your command sessions when seeking help like this, including the command prompts and return text. You can use /usr/bin/script to log the session, if that helps. Reason: Otherwise, we are left guessing on many key details, including even whether you are using root for privileged operations, or are attempting to use only regular user authority. Being able to see your verbatim shell session can help avoid wasted time for both you and your aspiring helpers. Any time you find yourself being tempted to say only 'it didn't work' when seeking technical help, odds are you really need to find a way to be a lot more specific. It's in your interest, seriously. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Secure Wiping hard drives
Quoting Brian Lavender (br...@brie.com): I would think that writing zeros to the disk would make the data unavailable in many cases and is relatively fast. IIRC, DBAN takes multiple passes with pseudorandom data. What if the fact that a melted disk leaked information? Yeah, you go tell LLNL's Security Office that they don't know their business. Let us know how that works for you. Personally, I would go one step further and use a pseudo random feed from AES with Cipher Block Chaining (CBC) and perhaps throw some salt in the middle so that it isn't too predictable. Really, because data are so much better hidden by overengineered pseudorandom data than by, e.g., 'All work and no play makes Jack a dull boy' over and over. Sure, that makes all kinds of sense. In some universe. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Secure Wiping hard drives
Quoting Darth Borehd (darth.bor...@gmail.com): We need a fast way to securely wipe hard drives. _How_ secure? LLNL actually melts the platters on hard drives retired from their security-sensitive computing vaults. Commercial operations generally consider DBAN good enough. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] grub 2
Quoting Brian Lavender (br...@brie.com): Any thoughts on grub 2? lilo still works -- and elilo if you have EFI-based hardware. I see that Debian squeeze is using grub 2. Default configurations were made to be fixed, nei? ;- ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] grub 2
Quoting Bob Scofield (scofi...@omsoft.com): Rick, What's the matter with GRUB 2? More than a bit baroque and overengineered for my taste, when something a lot simpler will do the job and (used correctly) be far more foolproof. I mean, good grief, they now have not just a conffile but an entire hierarchy of /etc/grub.d/ conffile fragments, 'support for non-ASCII characters, dynamic loading of modules, real memory management, and more' (http://www.dedoimedo.com/computers/grub-2.html). Sorry, folks, I just want to load a kernel image into memory, load an initrd, and mount a root filesystem. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Is there better spam detection?
Quoting Brian Lavender (br...@brie.com): It seems taht spammers have gotten keen to the Bag O Words Bayes analysis and now pump out some unrelated paragraph before they put in their spam. Nah, that's a really _old_ spammer trick. That's why you should never leave a Bayesian classifier set to autolearn, and instead should feed it spam and ham mboxes _you_ build with contents it'll benefit from. Is someone working on a meaningful spam analysis detection that I can use? In my experience, your best results are from a multifactor approach, with as much as possible of the heavy lifting being applied by MTA rulesets during the incoming SMTP session. You might want to use or at least study J.P. Boggis's prepackaged setup for Exim4: http://www.jcdigita.com/eximconfig/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Alternative to PHP Scripting
Quoting Gandalf Parker (gand...@community.net): But I am going to save it. If all a person knows is PHP I can see where it might be the shortest route. The PHP interpreter can also be used locally (e.g., via phpsh) without involving a Web server at all. (It was more than a little unclear whether the original poster lacked command shell access.) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] CalDAV
Quoting Peter Salzman (p...@dirac.org): [Bedework:] Sigh. It does look like a conquer the world type application though. Very impressive, but you hit the nail squarely on the head with the above paragraph. Even a broken clock's right twice a day. ;- (Seriously, I'd rather have a good scheduling server than be right, though.) I looked into mod_caldav. The documentation is spotty, but from what I can tell, it requires a patched Apache server?!? Dunno. I'm willing to look into it. I started to look into the Ubuntu calendarserver package. Please do let us know! Thanks. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] CalDAV
Quoting Alex Mandel (tech_...@wildintellect.com): You are aware of http://www.lugod.org/calendar/lugod-only.ics Other options on: http://www.lugod.org/calendar/ I'm curious: How is that data generated and maintained? And how is the RSS+XML generated? Is the code available? I have my own calendar (BALE) back-ended by a custom MySQL setup that has events, event templates, and groups tables. The data are served to the Web dynamically by a PHP snippet, though that's a bit wasteful of machine resources and I've been seriously considering generating static HTML via cronjob, instead. Only after that did people start saying 'Hey, can you also produce iCAL? Can you also produce an RSS feed?' Which would have been easier if it had been part of the design spec. I've hacked some Python that almost//sort-of produces correct iCAL output, but it requires some more work. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] CalDAV
Quoting Peter Salzman (p...@dirac.org): Actually, this looks absolutely fantastic. I can't figure out why it's not practically an industry standard. The main design goal is interoperability with all calendaring clients, is BSD licensed, and it looks very polished. Thanks for mentioning this. Bedework is mentioned very briefly (but, sadly, not covered otherwise) in this April 2008 rundown on Linux groupware: http://www.linuxjournal.com/magazine/scalable-opengroupwareorg That article is mostly about one of the alternative implementations, SOGo aka ScalableOGo. These pages look pretty useful: http://caldav.calconnect.org/implementations/servers.html http://wiki.herzbube.ch/index.php/DAViCal ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] CalDAV
Quoting Peter Salzman (p...@dirac.org): I can't figure out why calDAV isn't more utilized. I'll speculate: 1. Rapid standards churn. iCAL, xCal, iTIP, iMIP, vCalendar, vCard, BEEP, CAP, WebDAV, CalDAV Seems like CalDAV has become the surviving commodity standard, but those of us who watched the standards squabble over the yeard got a bit lost in all of the alphabet soup, and one suspects that a common reaction was 'Wake me up when all of this gets sorted out.' 2. Lack of enthusiasm for Java. Bedework, like UW Calendar before it, seems like a huge amount of Java infrastructure (servlets, directory services, a lot more) and a back-end database for a fairly basic set of scheduling functions that might possibly be achievable without so much... stuff. Seems to be a common syndrome, e.g., Chandler Server (Cosmo). And the non-Java alternatives are pretty heavy engineering, too. My own page on scheduling, which of course is way out of date and needs updating (see item #1, rapid standards churn): http://linuxmafia.com/faq/Apps/scheduling.html ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] CalDAV
I wrote: 1. Rapid standards churn. iCAL, xCal, iTIP, iMIP, vCalendar, vCard, BEEP, CAP, WebDAV, CalDAV Seems like CalDAV has become the surviving commodity standard, but those of us who watched the standards squabble over the yeard got a bit lost in all of the alphabet soup, and one suspects that a common reaction was 'Wake me up when all of this gets sorted out.' 2. Lack of enthusiasm for Java. Bedework, like UW Calendar before it, seems like a huge amount of Java infrastructure (servlets, directory services, a lot more) and a back-end database for a fairly basic set of scheduling functions that might possibly be achievable without so much... stuff. Seems to be a common syndrome, e.g., Chandler Server (Cosmo). And the non-Java alternatives are pretty heavy engineering, too. A bit further to that, speaking on a personal level: I keep hoping to find a moderately well debugged package, coded in C, or Python, or Perl, or Ruby, that I can just drop into my modest Apache2/Exim server without having to rearchitect everything, that would allow me to publish calendars and do free/busy event transactions that integrate with existing SMTP. I would expect to just enable WebDAV access support in my Apache2 setup, drop in the calendar thing, and have it Just Work without more fussing around. And that's just not happening. Everyone wants to make a groupware suite that does absolutely everything, wants to take over the world, and has incredibly picky and incredibly extensive requirements. I cannot just drop Bedework, or Bongo Project, or Cosmo, or Dingo Calendar Server, or ScalableOGo, or EGroupware into my old PIII server and have any of those play well with my existing server configuration. Almost all insist on a specific back-end database, and many want LDAP-based directory services. _Maybe_ Apple Calendar and Contacts Server will do a simple drop-in. Or Radicale. Or SabreDAV. I had hopes, some years ago, for Hula Project, which Novell killed off in the process of trying to turn it over to a third-party developer group. As the project was dying, Bongo Project was created as a fork from it. Here we are in 2011, and it's still a beta, but one of the cheering things about its Hula predecessor is that it did _not_ attempt to take over the world. Because they listened to Jamie Zawinski, who knows more than most people about how corporate overengineering can kill open source projects right in the design phase. Here's Jamie telling the story, and I do recommend spending the time reading it: http://www.jwz.org/doc/groupware.html Anyway, _maybe_ Bongo Project is an answer. Except, er... Mono? Really? Oh yeah, that's that Novell factor at work. And there are only unofficial packages for most distributions, because nobody outside Novell ever was enthusiastic for it. E.g.: http://download.opensuse.org/repositories/home:/bongo-project/Debian_6.0/i386/ http://download.opensuse.org/repositories/home:/bongo-project/Debian_6.0/all/ And look at all that stuff. Might as well be J2EE. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Problems with missing 'missing' file
Quoting Shwaine (shwa...@shwaine.com): Assuming that the \r is actually carriage return (and not a literal string consisting of backslash and the letter r) and that this was originally an older Mac formated file, you probably don't want to remove \r. I actually meant exactly what I typed, i.e., the backslash as an escape, followed by a character 'r'. That's the way you refer to an ASCII 13 carriage return control character in vim search strings. Line feed would be \n. Attempt to insert an actual CR into a vim ex-mode search string, and you won't get the result you had in mind. Whether that's specifically what the original poster needed, dunno. I really don't remember _precisely_ what he said at this point, and don't want to spend time looking it up. I recall him saying that he had some files with spurious embedded CRs and needed to remove him so related software can build, hence wanted to use a canned utility for the purpose. My point was that, regardless of whether you think you want to strip spurious CRs or spurious LFs or other such junk from a modest-sized text file, ex-mode search replace in vim is often the most pragmatic method, because, even if you screw up the search, you can trivially undo your change and try again differently. Older Mac files only have a carriage return to mark the end of line and do not have a line feed (\n, the end-of-line delimiter on Unix/Linux). So if you remove the carriage returns on an old Mac file, you end up with one very long line. As I said upthread, and I said again above, the good thing about attempting such a repair operation in vim is that, if you guess wrong about what to do, or implement it badly, you can mumble 'Oops!', hit u for undo, and you're right back and can get it right on Round Two. Better to check if there are line feeds No, better to just try out what you think is needed, and if you fumbled it, undo, try again two seconds later. Faster, gets the problem out of the way. Not worth the time to even remember all the antediluvian crap about 'Old Mac files terminate ASCII lines with CR only, other Unixes terminates ASCII lines with LF, DOS/Windows terminates ASCII lines with CR LF.' I'd reclaim those neurons for something actually useful if I could. The only slow bit is arguing with obsessives on mailing lists. ;- ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Problems with missing 'missing' file
Quoting Shwaine (shwa...@shwaine.com): And nothing about my reply contradicted this. In fact, my reply was just clarifying that the old Mac file format is just carriage return (\r) and not carriage return-line feed (\r\n) like the Windows format. This means that the vim substitution command to correct the Mac file format is NOT the same as the substitution command for correcting Windows file format. Which entirely misses my point that I was giving a general approach to cleaning up all endline problems. But, since you are making a point of saying so, actually your reply _did_ contradict my suggesting \r (and by implication, \n or whatever else is required) as a search string, erroneously claiming that one should use a literal CR if seeking to find ASCII 13 characters -- which, as I pointed out, is a blunder and doesn't work. Anyway, this is a poor use of my time at least, and I hope yours, too. Frankly, I don't see what was so controversial as to warrant such a long reply. I'll be delighted to dispose of further interruptions more briefly. What's so obsessive about giving people the correct information Ironically, your suggestion of using a literal CR is greatly broken. Check for yourself. Meanwhile, sorry, have to do real work. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Problems with missing 'missing' file
Quoting Shwaine (shwa...@shwaine.com): So wait, this whole argument is because I clarified that all the advice given by you, and added upon by myself, rests on the assumption that the OP meant a carriage return instead of literally a \r string? No. That is doubly mistaken, both in parsing what I originally said and parsing what I recently said. You'll have to re-read upthread, though, because in fact I was not and am not seeking an argument. This is why so few women are computer geeks. [...] You know, as a feminist for about five decades and counting, I find your groundless resort to crying 'personal attack' more than a bit problematic on multiple grounds. However, please see above about having no interest in argument. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Problems with missing 'missing' file
Quoting Eric Lin (notapplicable.h...@gmail.com): On Wed, Jun 22, 2011 at 03:43:54PM -0700, Cam Ellison wrote: I'm trying to compile a firmware flashing app (I have a MultiTech modem with a motorboating problem, and the firmware upgrade is said to be the answer) and keep running into the same error. The app was developed for OSX, but the notes say it will run on Linux. I have seen a suggestion that running dos2unix will deal with those $'\r' lines, but dos2unix thinks it's a binary file. I downloaded the source for this app and ran dos2unix on all the files. Afterward, I had to modify a few of the source files' headers to get it to actually compile. Also, I have automake-1.11, but make wanted automake-1.10 and aclocal-1.10, so I just made symlinks in my ~/bin folder. You know, it's really worthwhile getting to know how to do search/replace for such problems within vim. For one thing, if you try such a change and it doesn't seem to have worked correctly, you can just do 'u' to undo, and try to refine your change. In this case, something like :%s/\r//g is probably all you needed. That's : enters ex-type command mode % sets scope to all lines s search replace / delimiter ahead of spec to search for \r spec to search for / delimiter behind spec to search for and ahead of replacement spec / delimiter behind replacement spec (i.e., replacement spec is null, here) g and make the change globally, not just once. You can of course do the same operation in 'sed', but doing it inside the vim buffer gives you that ever-handy quick reversion. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] hacked site
Quoting Bill Kendrick (n...@sonic.net): Related, for a laugh: http://xkcd.com/327/ One of the classics, although most of us don't know the URL on sight the way we do http://xkcd.com/386/ . Still, for a lot of people, just mentioning 'little Bobby Tables' will get fits of laughter. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] (no subject)
Quoting Dr. Denny Scronek (pasze...@yahoo.com): Flaky is you promise to show up ... repeatedly ... and you don't. That's flaky ... in any profession, when you're dating a lady, you name it. I stand by my words. A fair reading of the wording of your prior post seemed to be that a good algorithm for finding 'a non-flaky Linux person' would be to request, on a Linux user group mailing list, one primarily serving a town ~50 miles away from you, that someone drive to your house and perform a consulting job for a stranger who's not even willing to do so much as read a logfile to help himself. Thus, by (apparent) implication, Linux users unwilling to do that are flaky. It's possible you didn't mean that. You do what you think is right, anyway, if you happen to regret that perception. Meanwhile, no offence, but I'd rather spend my time attempting to help people with more technical aspirations. It's just a lot more rewarding, in general. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] (no subject)
Quoting Dr. Denny Scronek (pasze...@yahoo.com): OK. Ah, you don't regret that perception, then (that you're impliedly calling the lot of us flakes). Too bad. Let's end this. Easily done. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm the guy with the infinite login problem
Quoting Dr. Denny Scronek (pasze...@yahoo.com): Can I ssh to it? Doesn't compute. Try again please. To translate, Bill was asking if you're set up so he can remotely login to the command line of your machine rather than needing to visit your house physically just in order to help you solve your problem. It would certainly be nice for you if someone's got the time and opportunity to visit you physically to help you. (I'm actually far too distant, down close to Stanford University.) Because that might not happen, and in order to assist while you weigh options, here's something you can do that will gather potentially very useful debugging information: 1. Press Ctrl-Alt-F1 . You should see a black-background text console screen with a system login prompt. Provide your username, then when prompted, your password. I expect you will successfully login, and will then be at a standard Linux system (bash shell) command-line prompt. Do: cd /var/log less X.org.log The 'less' program is a page-at-a-time display program (the name being a sort-of pun on the name of the 'more' program) that allows you to go up and down through the contents of an ASCII plaintext or similar file, including most logfiles. In looking at X.org.log, you will be seeing logged messages created when the X server process (the display engine) and related process start up, e.g., when you attempt login. The messages are (sorry!) a bit verbose, chattily talking about various aspects of the video-related hardware as it is probed and set to operating modes. What you are looking for is lines that indicate a serious problem of some sort. For example, you might see lines showing a series of initialisation failures starting with inability to enable video hardware acceleration, with the result that the AIGLX driver module cannot be loaded, with the result that the X server process died. One of the reasons to become familiar with the Linux command line is so you can deal effectively with such situations. For example, if you think you spot something meaningful in /var/log/X.org.log, you might desire to copy it onto, say, a USB flash drive or onto a remote shell account you have on a separate machine somewhere on the Internet. So, it would be handy to know how to manually mount a USB flash drive onto /mnt (or wherever), and it would be handy to know how to 'scp' (secure network copy) a file accross the Internet, e.g.: cd /var/log scp X.org.log pasze...@someinternethost.com: Unless you happen to be familiar with how to do such things, it might be more feasible to just jot down some notes on paper about what you find in X.org.log. While you are in /var/log/, it's a good idea to also look around to see if there are any other logs whose entries at the time you attempt graphical login might give clues. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Caught in an infinite login loop
Quoting Bob Scofield (scofi...@omsoft.com):
On Wed, 2011-06-01 at 06:07 -0700, Dr. Denny Scronek wrote:
This is my second shot at this. Posting, that is. My laptop is caught
in an infinite login loop ...won't except my password. Not a wrong
password/CAPSLOCK problem that I can see. Any takers? Running xubuntu.
If you Google this problem you will find about six different
explanations for login loop. Here is the solution that worked for me.
1) Do what Alex says and boot with a live CD.
2) Mount your xubuntu partition.
3) Go to /usr/share/X11/xorg.donf.d/ and create a file called
xorg.conf
In xorg.conf put the following:
Section ServerFlags
Option AIGLX off
EndSection
I'm probably the only person on this lists who has no idea what all of
this means. But it worked.
If someone on this list wants to interpret what I've put here, I'd be
interested in learning.
You don't actually need a rescue disk to do that repair, if you have
the basic ability to do bash shell operations. (Of course, *buntu
people often don't.)
What you did was construct a configuration file for the X.org graphics
engine ('X11 server') that turns off Accelerated Indirect
openGraphicsLibrary eXtension (AIGLX), which, loosely speaking, is a set
of calls for fully hardware accelerated graphics rendering. Whoever
suggested that remedy to you correctly speculated that your release of
Xubuntu's X.org / AIGLX software doesn't properly support hardware
accelerated graphics on your video hardware. Hence, whenever you try to
login, the AIGLX extensions choke and kill the X server, taking you back
to the login screen popped up by your X display manager, which is
probably the GDM one that XFCE4 likes to borrow from GNOME.
You probably could have determined that the step would be useful before
carrying it out by having a look at /var/log/X.org.log from the non-X11
bash command line. That might seem impossible because, you might be
thinking, 'How can I do system operations when I cannot login and X11
isn't working?' I'll get to that point, further down.
By the way, /usr/share/X11/xorg.conf.d/ (slight typo corrected) is not
really the ideal place to make that fix. /usr/share/X11/xorg.conf.d/
is a set of configuration snippets internal to the X.org engine that it
uses as hints for hardware detection. Although your creating an
instance of xorg.conf there _works_ in the sense that it alters X.org's
hardware detection to prevent it from trying AIGLX, the problem is that
that directory is / should be under the control of your package
management system, not under the control of you, the sysadmin. A better
place to create that file is /etc/X11/ , where it is guaranteed not to
get overwritten by package updates.
Anyway, let's get back to the original dilemma you faced. You couldn't
login, and therefore you needed a live CD to fix your system, right?
Actually, wrong. You _could_ login, just not via the graphical login
screen (the login screen GDM puts up for you). That's typically virtual
console #7, reached by doing Ctrl-Alt-F7. Do Ctrl-Alt-F1 to visit
virtual console #1, which you'll notice is plain, non-X11 console.
Visit each of Ctrl-Alt-F2, Ctrl-Alt-F3, etc., comparing them. Visit
Ctrl-Alt-F7 again, to verify that you can get back to GDM.
Go back to Ctrl-Alt-F1 (virtual console #1). Notice the text-mode login
prompt. You know what to do.
Hey, it worked. You're logged into your system and seeing a bash
command prompt, and all without X11! You're boldly going where hardly
any *buntu user has gone before. Do 'cd /var/log'.
Now, 'ls | more' that puppy. There are various logfiles from different
subsystems. Here are two bits of wisdom, useful in practically any *nix
debugging scenario:
o When in doubt, look for clues in the logfiles.
o 90% of *nix problems involve file/directory ownership permissions.
This is part of the other 10%, but the first rule applies: If you look
in /var/log/Xorg.log, you'll almost certainly see AIGLX choking at X.org
startup time. (The /var/log/Xorg.n.log variants are older snippets of
that same logfile that have been rotated out.)
OK, _without_ X11, how would you create /etc/X11/xorg.conf (or, if you
insist, /usr/share/X11/xorg.conf.d/xorg.conf)? That's where it's handy
to learn to use an ASCII editor progam, practically any ASCII editor
program, that is not dependent on X11. We sysadmins learn to use vi for
that purpose, despite its learning curve, for the simple reason that
there's some implementation of vi on every *nix system without exception
and it works even over anything more high-bandwidth than a tin can and
strings, and it works even if the system in question is pretty severely
broken. You might prefer 'ee', or 'nano', or 'joe', or something like
that -- but with the long-term drawback that they are not guaranteed
present on other people's arbitrary *nix systems.
If you want to try vi, the 'vim' implementation is the one usually found
Re: [vox-tech] [fwd] YouTube downloading
Quoting Bill Kendrick (n...@sonic.net): Since this topic has come up, and Rick's is a very thorough post on the topic... From CABAL mailing list, via SF-LUG mailing list. Hi, Bill. I am truly flattered. Sometimes, I post something like that after hours of careful research and write-up, hear nothing but silence in response, and wonder if anyone noticed, so it's really nice to get feedback. FWIW, I wrote that in part in order to FAQ the subject on the Web, which I've done as an addition to the Linuxmafia.com Knowledgebase, here: 'YouTube Downloading' on http://linuxmafia.com/kb/Web/ Thanks again. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Filename suffix dependent deletion problem with Samba
Quoting Peter Salzman (p...@dirac.org): It appears that Samba refuses to delete files with certain types of extensions, but I can't find any mention of suffix-dependent permissions in Samba, so something else must be happening that *looks like* suffix dependent permissions. Just an idea based on attempting to Web-search your problem: Try (temporarily) setting 'log level = 10' in smb.conf and restart the daemons. Then, re-try the deletion operation. Then, examine your logfiles to see what clues emerge about the root cause. I stress 'temporarily' because log level 10 chews up disk space at an impressive clip. (Disclaimer: Haven't had occasion to admin Samba since 1999, so the above is all I'm likely to usefully offer.) -- Rick MoenVila: Why don't you go? Avon: _You_ are expendable. r...@linuxmafia.com Vila: And you're not? Avon: No, I am not. McQ! (4x80) I am not expendable, I'm not stupid, and I'm not going. -- Blake's Seven ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Netflix
Quoting Jim Stockford (j...@well.com): how do you know online petitions are not worth...? if i were in charge of a company or department, i'd make sure y group was attentive to incoming electronic info. i'd at least try to ensure that the filters were sufficiently granular and produced useful statistics. it's a question: do you have info or are you jaded or some such? I suspect he has info -- and that it's the same info anyone who's taken a serious look at the history of online petitions and e-mail political campaigns arrives at: 1. The results are dead-easy to fake or alter -- notoriously so, to the point where Congressional aides politely ignore all supposed constituent letters arriving via e-mail (especially the 98%+ with oddly similar wording). 2. Generally, the petitions are venting exercises among people wanting a vendor to do something plainly not in the vendor's business interest. In this case, Netflix takes its marching orders from Our Lords in Hollywood, who have decreed strong and updatable encryption for anything at HD resolution, to control what the sheeple are permitted to. Period. If you get 100,000 people to say to Netflix 'Please provide your proprietary software for Linux x86 without requiring our machines to be DRM-imprisoned', they will find the nicest possible way to say no. And all those people signing petitions will have wasted their time and energy, having not paid attention to basics. But I guess they'll have felt a sense of accomplishment at having gone begging to a vendor. People apparently do. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Free cross platform database applications
Quoting Rod Roark (r...@sunsetsystems.com): Looking for an easy-to-use open source database management tool, maybe sort of like MS Access. 'Databases, Casual' on http://linuxmafia.com/kb/Apps/ is a place where I aggregate blurbs I've encountered about possible options. The usual disclaimer applies: I've not used them; I've only read about them. Disclaimer #2: It's been six years since I gave that page the once-over, so there may _well_ be good options not mentioned. At the time I last revised the page, this seemed to be an application category that on Linux/BSD was just beginning to flower. You will notice separate entries in the knowledgebase index for 'Databases, SQL' and 'Databases, xBase'. I divided out the original 'Databases' page into three parts, because it struck me that those types served almost completely different audiences and needs. -- Rick Moen Has Google looked at the appropriateness of indexing r...@linuxmafia.com #WikiLeaks? The answer is yes, and we decided to McQ! (4x80) continue. Because it's legal. -- Eric Schmidt ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Ubuntu 10.04 LTS upgrade woes
Quoting Ken Bloom (kbl...@gmail.com): A correct solution that covers all of the corner cases would be to replace the glob with find -path './.*' -maxdepth 1 Elegant. I like this a lot. -- Rick Moen You can stop running that response to Virginia's r...@linuxmafia.comletter about Santa. She's probably dead by now. McQ! (4x80) -- FakeAPStylebook ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Ubuntu 10.04 LTS upgrade woes
Quoting Chanoch (Ken) Bloom (kbl...@gmail.com): He wants *only* the dotfiles (and none of the regular files) [...] That's why he changed it to the following, which requires there be a non-dot character after the dot tar zcfv dotfiles.tar .[!.]* $ cd /tmp $ touch ..foo $ ls .[!.]* $ ;- (Yes, '.[!.]*' is nonethless a pretty good solution, among a myriad of imperfect ones.) -- Rick MoenSo, this SEO copywriter walks into a bar, grill, r...@linuxmafia.com pub, public house, Irish bar, bartender, drinks, McQ! (4x80) beer, wine, liquor. -- Michael Karlsson ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Which FTP server? Pureftp, Proftp or some other
Quoting Tony Cratz (cr...@hematite.com): I'm in a position again to set-up an FTP server. I'm looking for a good server which will support anonymous connections but limit what they can do. Both Pureftp and Proftp can solve this problem. I'm looking for arguments why I should choose one over the other or even a third option. In the past I used PureFTP. I have a friend who uses ProFTP. So I could go either way. http://linuxmafia.com/faq/Network_Other/ftp-daemons.html Consider vs-ftpd. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Problem with Gigabyte 890FX, Phenom II, and Kubuntu
Quoting Brian Lavender (br...@brie.com): Check the system event logs in the motherboard bios. Sometimes listed under SEL. Otherwise, I would stress test the machine. I used to run ctcs to burn in systems for a cluster I worked on for LLNL. It does memory, io, and cpu stress tests. http://sourceforge.net/projects/va-ctcs/ No longer maintained. See the successor fork: http://sourceforge.net/projects/ctcs2/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Problem with Gigabyte 890FX, Phenom II, and Kubuntu
Quoting Cam Ellison (c...@ellisonet.ca): This is my only machine, and it's a production machine, so I'm not sure about taking it out of service to run ctcs2 (thanks Rick!). You're very welcome. I have notes here, which I recommend, because Cerberus is rather peculiar software that takes a little getting used to, and has some quirks. 'Burn-in' on http://linuxmafia.com/kb/Hardware (We used to put all new or repaired machines at VA Linux Systems through at least 48 hours of Cerberus / ctcs testing, to catch problems.) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Problem with Gigabyte 890FX, Phenom II, and Kubuntu
Quoting Cam Ellison (c...@ellisonet.ca): On another list that I frequent, the two responses thus far both suggested replacing or swapping out the PS. I have to admit the idea has merit, though it's an Antec Signature 650, came new with the rest of the system, and over $200 here including the taxes. I'm a little leery of ending up with a good, but effectively useless, PS. Which leads to another question: how do you test a PS? Is it possible? I'm sure it's possible (at least in theory), but I never have tried. I've always just tried to keep around at least one of each major type with a piece of masking tape on it labelled 'known good as of [date]', and swap those into systems where I suspect the PSU. If the PSU is generally functional, then in my experience the usual question is whether it is too weak for the current draw asked of it. (In a perfect world, you would be able to believe manufacturer ratings, but of course they lie and exaggerate, and also doubtless some PSUs achieve their claimed ratings better loaded with some impedance types than others.) Antec PSUs are on the short list of ones I have faith in, generally. I have a confession to make: I really didn't pay much attention to this thread until I saw Brian mention CTCS (Cerberus), with which I have a great deal of experience. I've just now re-read your original posting to get the context for all this. That having been done, I think the suggestion of a (say, overnight) Cerberus run has a lot to recommend it. Cerberus puts a system under very, very serious load, which is the rationale for its use to stress-test newly constructed systems on the VA Linux Systems production line: It exposes most hardware flaws through thrashing the hell out of pretty nearly every hardware subsystem in the host. Your description (halted suddenly, no output, coldboot required) doesn't sound a-priori like a RAM problem. It's conceivable that it's a software problem, but my instinct says hardware is more likely. That instinct says it's likely to be something with either the motherboard + CPU or with the PSU. One avenue towards diagnosis (generally speaking and probably _not_ useful for your situation; this is just for general knowledge of troubleshooting) is to simplify the hardware situation temporarily for diagnostic purposes, to attempt to isolate the problem. That is, open up your system and look at what's plugged into what. Do you have expansion cards that can be disconnected and the system is still able to produce video? Remove them. A miniPCI-format wireless card? Unplug it. Non-boot hard drives? Unplug and detach them. Optical drives? Unplug and detach them. Get as close as you can to just motherboard + PSU and still have the system be functional enough to run and expose the syndrome if it's still present. That method is useful primarily for symptoms that express strongly and constantly, like 'System doesn't even beep or produce video'. In those cases, you detach every non-essential subsystem and see if the remaining hardware then beeps and does video. If it does, then the root cause lies in one of the subsystems you detached -or- in the 100%-wired-up system trying to draw too much current from a borderline PSU. If if doesn't, then the problem may be in the system core (motherboard, PSU, CPU, RAM). The latter case is of course tough to narrow down. If you have multiple sticks of RAM, and the motherboard northbridge can function with fewer than all of them, try with half the RAM, then with the other half, seeing if bootup beep + video reappears and correlates with one bank of RAM but not the other. Getting back to steps more likely relevant to _your_ problem, the other general class of diagnostic techniques involve swapping in known-good components, and seeing if the problem suddenly vanishes with one such swap-in. The pain-in-the-ass requisite is, of course, having a bunch of known-good parts sitting around for this purpose, which one only rarely has. Sorry, I don't know any easy way around that. -- Rick Moen Told my friend she shouldn't smoke weed while she's r...@linuxmafia.com pregnant because her baby's never going to want to McQ! (4x80) come out. -- Kelly Oxford ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Problem with Gigabyte 890FX, Phenom II, and Kubuntu
Quoting Cam Ellison (c...@ellisonet.ca): With regard to the rest of your email (snipped out), I'll try that if nothing comes from CTCS. Two halts five weeks apart doesn't give me much to work with. Yes. One of the Bad Words that one doesn't really want to hear when performing diagnosis of any kind, including on computer hardware, is 'intermittant'. I did try dmidecode on the PS, but drew a blank, perhaps not surprisingly. On the basis of your instincts, plus my own suspicions and previous experience (now that I think about it), I'm beginning to suspect the PSU. Could be. FWIW, this would be the very first time I'd heard of an Antec PSU being the root cause of a system problem. They're really good. However, there's always a first time. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Vipre and ESET Antivirus
Quoting Bill Kendrick (n...@sonic.net): Tsk tsk, this is off-topic for a Linux group! ;) You know, that's actually something I've until now understood to be (idiosyncratically to LUGOD) not the case, because of the way the mailing list was chartered. (Please note, I'm not challenging what you're saying, Bill. I'm just saying I've previously heard differently.) Specifically, the listinfo page says 'All Linux and computer related technical questions and discussions go here', and the page title says 'vox-tech -- lugod's technical discussion forum'. Over the years, it has seemed as if 'computer related technical questions' had been construed to encompass non-Linux OSes and applications as well, which is why until today I'd not been surprised to see those discussions occur frequently without objection. Again, no problem whatsoever if you want to see concentration on Linux. I'm just saying it looks like a small shift from prior policy, as I understood it. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Which distro for file/print/web server
Quoting Bill Broadley (b...@broadley.org): While technically true, often eSATA is combined with a multidisk chassis and has a lame/broken chip that multiplexes a single SATA connection to multiple drives. Said lame/broken chip often hides the SMART data. Yes, definitely don't buy those. I find is similarly frustrating when the RAID controller does the same thing. It's really really annoying to have to pull a failed drive to get it's model and serial number so you can RMA it. Well, sometimes there are compensating advantages to the RAID controller, and ways to query the latter to determine the model and S/N of the failed drive. Not that I'd recommend one, but my old firm VA Linux Systems sold a lot of Mylex RAID HBAs that met that description. The studies that I've seen show SMART is useless for predicting failures. That depends on what you mean by 'predicting failure'. You can use the SMART data to determine how many hours of online use the drive has had, and replace it before it approaches MTBF. You can also note the pattern of accumulating errors and reallocations, a sharp rise in which correlates well with some failure modes albeit not many others. (The Google paper notes this fact.) Frankly, my main concern is many HD manufacturers' tendency to make their drives lie when reporting such data. I have my hunches about which manufacturers and model lines are most guilty of this lying, but can't prove it. Alternatively, you can just RAID1 drive pairs, and deal with failures as they arise without particular worry in advance. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Which distro for file/print/web server
Quoting Alex Mandel (tech_...@wildintellect.com): The big downside I realized today, you can't get any HD stats on an external USB drive(smartmontools). So I've got no health monitoring of the disk. Thanks for posting. Fascinating stuff. I realise you won't want to re-do the design -- which sounds terrific with that one proviso -- but I notice the Zotac box also has one eSATA port. It strikes me that that eSATA might be The Right Thing. What I'm hoping to find, as an eventual replacement for my 2001-era 2U server, is a good nettop box with a pair of eSATA connectors. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Which distro for file/print/web server
Quoting Alex Mandel (tech_...@wildintellect.com): Good Call, I did look a little at finding a drive case that was both eSata and usb. The drive case was the cheapest part by far but esata/usb isn't so common. I'm not sure if the board in between would still be an issue. If I happen to come upon a good deal on such a case I might try it. Anyone have an external eSata they could try to get SMART data on? All libata drivers support SMART -- which is what one would expect, given that libata leverages the kernel's SCSI layers. https://ata.wiki.kernel.org/index.php/Libata_Feature_Table (The particular SATA interface, internal vs. eSATA, is not an issue.) For SATA drivers that aren't part of Jeff Garzik's libata collection, you would have to check the particulars of those drivers. But I expect most people would use libata drivers. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Which distro for file/print/web server
Quoting Alex Mandel (tech_...@wildintellect.com): Ha, turns out I did get a case with eSata, didn't realize it until I started shopping for another case and went That looks familiar... Just need to find a cable now to try it. I'll let you know how it goes. http://www.newegg.com/Product/Product.aspx?Item=N82E16817173043 I predict that you'll be happier with SATA than with USB for this deployment. USB entails an additional translation layer, which is why you lose things like SMART datastreams, whereas eSATA simply extends the native mass-storage bus. Also, you should find that external SATA is more reliable and has fewer sources of flakiness and has fewer speed limitations in real-world situations. http://en.wikipedia.org/wiki/USB_2.0#Transfer_rates http://en.wikipedia.org/wiki/SATA#SATA_Revision_2.0_.28SATA_3_Gbit.2Fs.29 ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NAS/Printer Server/Web Server?
Quoting Alex Mandel (tech_...@wildintellect.com): [Interesting details about hardware options you're considering:] Note to self: For some reason I'd never really thought about the fact that you should put such a device on a UPS. In hindsight, this is probably what killed my previous NAS drive. Are you thinking it was a power surge / spike or low-voltage line condition that fried the drive? Out here on the Left Coast, serious line-power problems are pretty rare, especially compared to what, say, LILCO customers have to put up with in the NYC area. But the matter is worth pondering. I have for a couple of decades run full-service *ix servers at my residences on (variously) T-1 and broadband, so I weigh some of the same concerns you do. In April 2009, the machine then running linuxmafia.com, a 1998-era VA Research model 500 2U server I literally rescued from a dumpster one day around year 2000 while working at VA Linux Systems, got fried during a late-spring lightning storm, and I hastily replaced it with a slightly less ancient VA Linux model 2230. That's the only time I've ever lost hardware from AC power fluctuations (in the Bay Area, anyway). Back in summer 2001, when California went through rolling blackouts, I pondered getting a UPS but decided it would be solving the wrong problem: My suffering small amounts of downtime when PGE lost power was OK as long as the machine came back up. So, the missing ingredient was reliable journaling filesystems, and I figured out how to migrate my system from ext2 to XFS. (See 'XFS Conversion' on http://linuxmafia.com/kb/Filesystems . To explain, ext3 was not then production-ready.) Still, it's bothered me to have my hardware, particularly HDs, exposed to PGE-caused damage _if_ that actually happens. So, I went shopping -- and _still_ found UPSes to be a solution to the wrong problem. Instead, I bought an APC-branded power filtering / conditioning unit, thereby addressing the power-quality issue without saddling me with a failure-prone lead-acid battery. Also, having recently bought an external (USB/Firewire) 2 TB drive and been astonished by the low cost, I'm considering buying a second one of those (to make a RAID1 pair) and, say, a ShivaPlug to replace the model 2230: That would cut the electricity hit to almost nothing -- and still let me use standard Debian on real mass storage. Anyway, think twice before putting printers on your UPSes (if that's part of what you're considering), as many printers draw gobs of power when in service, and are not typically an essential service you need running during power outages. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NAS/Printer Server/Web Server?
Quoting Alex Mandel (tech_...@wildintellect.com): Anyone have any thoughts on connecting something like the following as an external usb 2 drive hardware RAID? http://www.newegg.com/Product/Product.aspx?Item=N82E16817182144 http://www.newegg.com/Product/Product.aspx?Item=N82E16817121060 That's just two drives in one box. (Personally, I rather like the idea of each drive having its own USB/Firewire box w/PSU: No SPoF.) You would need to furnish your own hardware RAID HBA. I'm unclear on how you'd do hardware RAID serving to _USB_: By contrast, if you used the eSATA connectors (instead of USB), you could, I guess, but I'm (speaking for myself) a little unenthusiastic about SATA hardware RAID, generally. Be careful what you pick; most RAID-capable SATA HBAs are still fakeraid (manufacturer-specific software RAID). I guess the other question, for a use case like this, infrequent copies of data for backup does it matter if it's software or hardware RAID? I kind of liked the idea of just popping in a drive and having build the RAID without me doing anything. I don't think configuring md RAID1 for remirroring is exactly a big deal, is it? Actually, I'll be able to speak to that question soon, because my server's recently failed one of its md RAID1 mirrored pair of antique 18GB SCSI drives, and I'll need to replace it RSN. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NAS/Printer Server/Web Server?
Quoting Alex Mandel (tech_...@wildintellect.com): I was going to go with RAID 1 using 2 TB drives. Got a line on 2TB externals with longer than 1 year warranties (since buying drives themselves comes with 3). At a cost difference of $150(Sheeva is about $100, the ReadyNAS is $250) I don't see myself saving much buying cases and drives. As I just mentioned, my server's running a degraded RAID1 pair at the moment (failed drive), which is why I picked up a 2 TB external USB/Firewire thing as a bandaid. (It makes ensuring that I've made safety copies of key filesystems frequently really easy.) http://linuxmafia.com/pipermail/conspire/2010-June/005493.html http://linuxmafia.com/pipermail/conspire/2010-June/005495.html http://linuxmafia.com/pipermail/conspire/2010-June/005510.html The thing is a Hitachi HSD2000 'SimpleDrive'; $150, 1yr warranty. I was/am really very short on time for screwing around with hardware, so the first simple, realiable-tech solution I could find at Microcenter won. (I'm not posting it to claim it's great or to recommend it, just to say that it solved a problem of the moment. The data-saving solution you actually do that works wins over the better solution that you never get to.) That would also be 3 power plugs instead of one Single points of failure are bad. Power strips or PDUs with master switches on them are cheap. (FWIW, the Hitachi spins down and shuts off if the attached host powers off.) What do you think about the RAID case for $50 I posted in the other part of the thread? Seems to be the same as buying 2 reliable single drive cases? Nope. SPoF. And why are you calling that a 'RAID case'? Looks like a JBoD to me. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] NAS/Printer Server/Web Server?
Quoting Alex Mandel (tech_...@wildintellect.com): I don't really know either, the only time I've had to mess with RAID was on a clunky old workstation with 3 drives and a terrible RAID BIOS. Doesn't seem a big deal. In my case, I'll need to muck about with /sbin/fdisk for a bit, because the mirrored pair has five filesystems plus swap: linuxmafia:/etc/bind# fdisk -l /dev/sdc Disk /dev/sdc: 18.3 GB, 18351959040 bytes 255 heads, 63 sectors/track, 2231 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000c1659 Device Boot Start End Blocks Id System /dev/sdc1 12231179204765 Extended /dev/sdc5 1 243 1951834+ fd Linux raid autodetect /dev/sdc6 244 425 1461883+ fd Linux raid autodetect /dev/sdc7 426 790 2931831 fd Linux raid autodetect /dev/sdc8 791 851 489951 82 Linux swap / Solaris /dev/sdc9 8521580 5855661 fd Linux raid autodetect /dev/sdc10 15812231 5229126 fd Linux raid autodetect I _could_ have made all of sdb and sdc be a single Linux raid autodetect volume md0 and then fdisked that, but I didn't want to mirror the swap space. Given that setup decision, I'll need to power down, crack the case, yank out and replace /dev/sdb with a fresh [sic] 18GB or so SCSI drive -- if I still have any -- and make a partition table on it of the above specs. Then, apparently I'll do: raidhotadd /dev/md0 /dev/sdb5 raidhotadd /dev/md1 /dev/sdb6 raidhotadd /dev/md2 /dev/sdb7 mkswap /dev/sdb8 swapon -a raidhotadd /dev/md3 /dev/sdb9 raidhotadd /dev/md5 /dev/sdb10 (Yeah, I know, 18GB SCSI drives in 2010 are a bit silly. All I can say is, time flies. I should at least fish into the pile and see if I have a pair of spare 73 GB ones -- though that will mean re-doing the partition maps.) Single point of failure on the power supply doesn't worry me too much since I can live with downtime and it's seems to be a relatively ordinary part. No, you should worry. Chief causes of HD catastrophic failure (other than simple age and wear) are misbehaving PSUs and heat stress. Putting both drives in a single external enclosure with a single PSU means they can be both taken down at once by the same misbehaving power supply or the same seized-up fan. At that point, you have just eradicated the entire point of having a RAID1 mirror pair. It will mean more work to configure since the NAS boxes seem to have print serve, file server, media serve all ready out of the box. Yeah, well, for present purposes I'd rather run a Linux server using simple, commodity, general-purpose components. Works for Me.[tm] ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Looking for a Sunbird (Google Calendar) replacement
Quoting Scott Miller (scottli...@gmail.com): http://www.mozilla.org/projects/calendar/sunbird/download.html Yeah looks like sunbird is not in development anymore. Their site says This is the last public Sunbird release by the Calendar Project. We recommend upgrading to Thunderbird 3 and Lightning 1.0 beta1. I should note that Lightning basically _is_ Sunbird. Sunbird was a bunch of XUL interpreted code for iCAL / CalDAV / DAViCal functionality atop the Mozilla portable runtime. Lightning is that same XUL code refactored to run on the Mozilla portable runtime inside Thunderbird 3.0.x or SeaMonkey 2.0. It might be possible to run it on Firefox's copy of the Mozilla portable runtime, though that's not addressed in the Web site's docs. Seems likely that there's been enough rewriting to accomodate Thunderbird 3 as host that that might be nontrivial. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Looking for a Sunbird (Google Calendar) replacement
Quoting Tony Cratz (cr...@hematite.com): While I understand that Lightning is really Sunbird it is not a standalone client. It requires having Thunderbird up and running. I really want a true standalone client which does not require any Internet connection, this is where Sunbird was a major win over Lightning. Yes, I do understand your dilemma. You could try seeing if you can hack the glue code so as to use just what's needed from Thunderbird's own XUL / C++ / JavaScript / CSS to support the Lightning XPI on top of Gecko (the Mozilla runtime). However, I suspect that'd be way too much work, since Mozilla Foundation (/Oracle Corp./whoever) appear to be targeting Outlook/Exchange schedule event handling, and thus see scheduling as incidental to e-mail. There was a time when I kept track of scheduling apps in Linux development space (both client and server end), with a particular interest in iCalendar support. You can find that in my Web site's knowledgebase in the obvious place (http://linuxmafia.com/kb/Apps, I think). However, I kept seeing projects wander off into some painfully overengineered groupweare direction, rather than doing a nice, clean, simple implementation, and became a bit disheartened, so my page on the subject is a little out of date. There is also: http://en.wikipedia.org/wiki/List_of_applications_with_iCalendar_support ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] MTA
Quoting Chanoch (Ken) Bloom (kbl...@gmail.com): The best thing to do is probably to install a lightweight non-daemon mailer like esmtp-run so that programs that need it can still have access to a sendmail command. Note that esmtp is no longer being maintained, but may still be useful nonetheless. I maintain a list of similar software, here: http://linuxmafia.com/faq/Mail/nullmailers.html -- Rick Moen Well, my terminal's locked up, and I ain't got any mail, r...@linuxmafia.com And I can't recall the last time my program didn't fail; McQ! (4x80)I've got stacks in my structs, I've got arrays in my queues, I've got the: Segmentation violation -- Core dumped blues. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] MTA
Quoting Chanoch (Ken) Bloom (kbl...@gmail.com): On Thu, Apr 29, 2010 at 09:50:56AM -0700, Rick Moen wrote: Quoting Chanoch (Ken) Bloom (kbl...@gmail.com): The best thing to do is probably to install a lightweight non-daemon mailer like esmtp-run so that programs that need it can still have access to a sendmail command. Note that esmtp is no longer being maintained, but may still be useful nonetheless. I maintain a list of similar software, here: http://linuxmafia.com/faq/Mail/nullmailers.html esmtp is the most capable in terms of outgoing encryption and authentication (It's been a while, so I don't exactly remember the details), so it's a good match for Google's SMTP servers which require those. Those details are highlighted on my page. ;- ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Exporting multiple sheets to CSV?
Quoting Bill Kendrick (n...@sonic.net): _Is_ there a way to dump every sheet in an ODS file into individual CSVs, without going doing a bunch of manual labor? Via macro. http://www.openoffice.org/servlets/ReadMsg?list=usersmsgNo=193847 ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Exporting multiple sheets to CSV?
I wrote: Via macro. http://www.openoffice.org/servlets/ReadMsg?list=usersmsgNo=193847 By the way, the key to finding that was to change my search query from openoffice export multiple spreadsheets to openoffice export multiple sheets ...as that's the local jargon in OO.o Calc (sheets, not spreadsheets). No luck whatsoever until I realised that. -- Rick MoenThe suffix '-bate' means 'to lessen.' r...@linuxmafia.com Yeah, we were surprised, too. -- FakeAPStylebook ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] my site was hacked
I inadvertantly sent this comment offlist, the first time. My apologies! Hai Yi (yihai2...@gmail.com) wrote: Tony: I use dreamweaver to edit my files locally and use its internal ftp to upload them. So, are you sending your password unencrypted across the open Internet? ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Netflix and Linux
Quoting Darth Borehd (darth.bor...@gmail.com): I've been trying to get Netflix's Watch Instantly feature to work on Linux. I've installed Moonlight, WINE, and User Agent Switcher for Firefox (to spoof their website into thinking I am running IE 7). I tried going through Boxee too (total bust). I'm out of ideas. Anybody been able to crack this riddle? You might be able to make it work using all-Win32 versions of everything under WINE or some other Win32 environment _under_ Linux. This matter came up recently on another mailing list, so I'll just quote from my post: This appears to be Microsoft Corp's PlayReady DRM shipped with the Silverlight software. Checking around, I see that they deliberately restrict which OSes the DRM OKs operation on. For example, OS X operation is OK'ed by the DRM software only on Intel-based Macs running Silverlight 2.0. I.e., even PowerPC Mac OS X users running Silverlight 1.0 are shut out. Microsoft's been sucking up to Our Masters in Hollywood, and pushing the ability of PlayReady DRM to control customers, for some time. See, e.g.: http://www.microsoft.com/presspass/press/2008/apr08/04-14SilverlightContentPR.mspx http://www.betanews.com/article/First-look-at-DRM-for-Silverlight/1208194304 http://www.reddit.com/r/linux/comments/ages9/hands_on_moonlight_2_brings_silverlight_2_bits_of/ Note: Microsoft licenses PlayReady today for certain use cases, but they do not have a port for Linux which prevents Moonlight from using it. It is very unlikely that we will get PlayReady DRM on Linux. -- Miguel de Icaza Our Masters in Hollywood don't mind providing PlayReady DRM on a Linux-based embedded device that's sufficiently well handcuffed, however, such as the Roku Netfix Player: http://www.linux.com/archive/feature/142729 Note comment: Actually, I doubt the claim that Netflix chose Windows Media DRM because they bought a system from Microsoft; my guess is they chose it because it's the only system the content owners allow them to use. I work for a company that runs on-demand movie services. Everybody I've met on the retail side of this industry hates DRM and I'm sure Netflix doesn't like inflicting it on their customers. However, thus far, content owners, particularly larger ones, have been entirely unwilling to license their content to on-demand services that don't use DRM, and Windows Media is the only DRM implementation that is even slightly viable (yeah, it's broken, harmful technology. You don't have to convince me.) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Ubuntu not booting after Kernel update
Quoting Darth Borehd (darth.bor...@gmail.com): Why LILO? I can't think of a single thing LILO can do that Grub can not do better. 1. Simplicity. 2. Ability to boot any arbitrary filesystem without the need for the bootloader to understand filesystem semantics.[1] [1] This isn't a problem with current common Linux filesystems, but has been in the past, and in some cases such as ReiserFS has limited GRUB to booting from some filesystems if mounted with the notail option. Admittedly, GRUB also does support a block list reference mode analogous to LILO's ability to find bootable objects by logical CHS location, but this is poorly documented and probably poorly tested. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Ubuntu not booting after Kernel update
Quoting Peter Jay Salzman (p...@dirac.org): I think I understand what you're saying, but I believe the argument for simplicity is more compelling from the point of view of the person using the application, not the application itself. Over a decade-plus of observing, 100% of those seemed to amount to I messed with my boot files or MBR, and then forgot to re-run sbin/lilo to make sure I had a bootable config before rebooting. Those holes in people's feet did hurt, though, I'm sure, even if the bullets were fired downwards. Based on the amount of hair pulling, simplicity for me goes to Grub, easily. I can't recall the last time I had to diagnose a Grub issue. I don't either, because I make sure my system's bootable after any fooling with the boot files and before rebooting. However, other people seem to have problems, which are then made considerably more difficult by GRUB's indisputably far greater complexity. E.g., read this thread, which I believe may still be unresolved: http://linuxmafia.com/pipermail/conspire/2009-October/005061.html http://linuxmafia.com/pipermail/conspire/2009-October/005062.html http://linuxmafia.com/pipermail/conspire/2009-November/005063.html http://linuxmafia.com/pipermail/conspire/2009-November/005092.html http://linuxmafia.com/pipermail/conspire/2009-November/005093.html http://linuxmafia.com/pipermail/conspire/2009-November/005096.html http://linuxmafia.com/pipermail/conspire/2009-November/005098.html http://linuxmafia.com/pipermail/conspire/2009-November/005102.html http://linuxmafia.com/pipermail/conspire/2009-November/005110.html http://linuxmafia.com/pipermail/conspire/2009-November/005117.html http://linuxmafia.com/pipermail/conspire/2009-November/005122.html http://linuxmafia.com/pipermail/conspire/2009-November/005125.html http://linuxmafia.com/pipermail/conspire/2009-November/005129.html http://linuxmafia.com/pipermail/conspire/2009-November/005132.html ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Fwd: Very slow off net
Quoting Bill Broadley (b...@broadley.org): I'd suggest adding caching in there somewhere, probably assumed. I've yet to find a nameserver package of any sort, recursive, authoritative, or even merely forwarding, that doesn't do caching. Agreed. Large ISPs (like pacbell) often have overloaded DNS, not to mention the DNS is often on the wrong end of a busy network. That's only the beginning of their problems. To the predominant dog-slow performance would add pervasive cache poisoning, e.g., the quality of being a security menace, as the next obvious problem to mention. But better to just skip them. I suggest unbound. I like Unbound, despite its relative youth. PowerDNS Recursor is also good, and perhaps a bit better tested. I would also consider MaraDNS. I'm extremely happy with the authoritative-only server published for quite a while by the same .nl TLD people who've more recently followed up with Unbound, FWIW. It'll also improve performance over using OpenDNS, Sort of. For cache hits, yes. For cache misses, not to much. Obviously, I was talking about cache hits -- which predominate if you run a recursive nameserver for a long while. Sure, so only your ISP instead of opendns and your ISP knowing everywhere you visit. The problem of your upstream link(s) being able to traffic analysis on where your packets are sent to, and inspection in cases where you don't bother to encrypt them, is a separate problem. But you knew that. Also, unlike OpenDNS, they have fiduciary obligations to you under contract. But you knew that, too. Use OpenDNS, and a party who owes you no loyalty whatsoever has a central record of all DNS queries your IP has attempted. NXDOMAIN does bug me, I believe that optional if you login/create an account. That deliberate RFC violation _should_ bug you. It's essentially saying Nothing but the Web counts. Correct DNS information for SMTP mail doesn't matter, because it's not the Web. I'm not clear on why a login would remove that misfeature. They use the ads on their Site not found Web pages to generate the revenue stream that underwrites the service. Oh, almost forgot. I'd recommend unbound as a local caching recursive server. It's DNSSEC and DLV aware I'm no DJB fan, but I think he's right about the reasons why DNSSEC is never going to be used on any significant enough scale to matter. The DLV lookaside kludge (that partially works around lack of a signed root zone) to an overengineered and impractical based spec strikes me as just another deck-chair on the sinking ship. I don't know why I should trust DLV repositories (Trust Anchor repositories), and the largest one that makes something like a meaningful effort to validate that they belong to whom they claim to (ISC's) had a whopping total of 25 DLV records in it a year ago, when I last looked into this. (SecSpidor collects DLVs, but doesn't validate them.) So, good luck making that stuff practical and useful. Do send a postcard. ;- Anyway, FWIW: http://linuxmafia.com/faq/Network_Other/dns-servers.html ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Fwd: Very slow off net
Quoting Richard Harke (paleopeng...@gmail.com): That leaves the question: why access DNS at all for a application launch? Again, what application, for example? And by what means do you know that that application is doing DNS lookups? You say I've done some tracing, but I don't know what you've done to associate DNS lookups with particular non-network-oriented applicaitons. Once you know what application binary you're talking about, you can run it under strace to determine what system calls it's making. By the way, IMO, you really should consider running and using a local recursive DNS nameserver. Doing so improve performance a great deal over using your router on your home network, which almost certainly is merely a forwarder. It'll also improve performance over using OpenDNS, along with not giving the operators of that service detailed information about your Internet activity, _and_ (unlike OpenDNS) it would actually implement DNS technical standards correctly (i.e., correctly answering NXDOMAIN when that's the truth). Possibly of related interest: http://linuxmafia.com/pipermail/sf-lug/2008q3/005308.html http://linuxmafia.com/pipermail/sf-lug/2008q3/005309.html ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
