[25876] in Source-Commits
Re: /svn/athena r25272 -
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Tue Jul 26 09:37:31 2011
Date: Tue, 26 Jul 2011 09:37:24 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
cc: source-commits@mit.edu
In-Reply-To: <71E78E51-F2FB-4B5E-976C-6D268BF8E7F1@mit.edu>
Message-ID: <alpine.DEB.2.00.1107260935170.1735@tyger.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 26 Jul 2011, Jonathan Reed wrote:
>
> On Jul 26, 2011, at 9:20 AM, Geoffrey Thomas wrote:
>
>> Bah.
>>
>> 1. It might make a lot more sense to use the installer's existing syslogging support instead of writing our own log. (As a side benefit, syslogs are timestamped.) You can use what appears to be a reasonably standard logger(1) to send messages. They end up in /var/log/syslog.
>
> Ah, I didn't realize we had "logger" at this point.
>
>>
>> 2. I'm skeptical that your netcat MTA works. The client not waiting for server responses is one of the biggest giveaways that a message is spam before it's even read; I suspect this will be highly unreliable. The installer has a built-in httpd for getting debug logs off -- you can just run "httpd", which will spawn a daemon serving /var/log over port 80, or you can do something involving `udpkg --configure --force-configure save-logs`, which also symlinks a few useful things into /var/log. (The latter is what the installer main menu's "Save debug logs" option runs.
>
> It worked repeatedly in my testing, but httpd is possibly a better
> option. However, I'd like something that doesn't require the user to
> keep the machine sitting there forever until someone from release-team
> can look at it.
Okay, if it's tested and works I'm a bit less skeptical.
>> 3. If networking doesn't work, how is sending mail supposed to work?
>
> If networking doesn't work, how is httpd supposed to work?
>
> Even with an 18.2 address, you can talk to 18/8.
Well, that's also a problem, but at least the d-i menus will warn you that
networking isn't configured and so this may or may not succeed. You do
also get the option in the menus to save the logs to a local disk
somewhere.
I'm just saying that, if we suspect the problem is networking being
broken, we're not getting logs off the machine via any networking-based
method at all, so the answer will probably involve looking at the debug
logs on tty4 (and maybe taking a screenshot via cell phone camera).
> I'll have a second draft shortly.
>
> -Jon
