Is there to be a BoD meeting tomorrow?
Is there an agenda?
Lacking the policy.cf to refer to, what items will be covered (assuming there
is no "formal" agenda, of course)?

13 responses total.

Yes, there is a meeting tonight (Wednesday) at 7:30.  Any item that
has been discussed for at least 7 days is fair game.
        Realistically, though, I expect the meeting to be short.
The feature of the meeting will be Karyl Stein's M-Net update report.
        I also will ask for action on the following motions of mine:
        1.  Motion to rescind the changes the BoD made in the Party
program last month.
        2.  Motion to approve in principle moving Arbornet from the
NEW Center.
        Linda says she has an emergency motion on the Art Fair which
she wants acted on.

Had the meeting.  The system is nearly ready to bring back up, but karyl want
s a full backup done first.

He says it seems to be functioning in crackerjack fashion.  Looks good.

The e-mail seems to be a function of the ISP.  We thought this a while back,
but they said we needed to upgrade to bsdi 2.1 to correct our internal
problems first.  This having been done,t he problem remains, adn they will
be gettijng a serious call tomorrow.  Not oue problem, guys.  Your turn to
fix it.

WE will be meeting on saturday at noon at DPc,s to build the new booth for
Art Fair.  If youa re handy with a hammer, stop by and we will put you to
work.

bap and krc have been appointed to the audit committee.  

A full report once m-net is back on line.

How is e-mail a function of the ISP?  Do they have you behind a firewall
that's blocking port 25, or soemthing?

why build a booth to advertise something that keeps failing 

what happened to the previous art fair booth?

I think that is where grex is moving too.....hahahaha

movin where?  I haven't kept updated with all that

Email and all the checks seem to work on m-net just fine as long as it is
within m-net.  What they said is that CtC has two servers, and maybe only one
is configured right for m-net, perhaps the discrepency is there.  I am not
techie enough to state it properly.

The way an ISP can hose up e-mail is by having improper MX records in the DNS
database/
This will point mailhosts all over the internet to the wrong place.
I don't know if that's what was going on, but it  is an easy enough
mistake to make. (And easy enough to fix, I might add.)

Arbornet does indeed have "weird" MX records, but that's not the
problem.  arbornet.org has two mx records, but they both point to m-net.
m-net also has one mx record, which points to m-net.  The two records
for arbornet are redundant; only one is needed.  The mx record for m-net
is superfluous, mail would be delivered just as well without it.  In
fact, strictly speaking, none of the mx records are needed.  The two
reasons one uses mx records are (1) to arrange for a backup site if the
primary site is down, and (2) to specify a host for a domain address
that does not have an A record, or to specify an alternate location for
a host that is not intended to directly receive e-mail.  Neither of
these cases are true for m-net so, while the mx records are harmless,
they are not necessary.

The easiest way to see the problem is to say "telnet m-net.arbornet.org
smtp" (note that grex's ip block will deny this for non-members).  You
will find you are disconnected nearly instaneously.  If you can spy on
the internet traffic, you will find that your end sent a SYN packet to
m-net, and that m-net sent back a RST packet.  The most likely cause is
that m-net is not, in fact, accepting smtp connections.  The other
possible cause is that m-net's ISP has a firewall (actually, a filtering
router) that "fakes" RST's for smtp ports.  This is not, in fact, real
likely, because such routers typically send ICMP packets with
"destination unreachable" error codes instead.

To verify that m-net is not, in fact, accepting connections, you can
say: "netstat -an | egrep 25" on m-net.  You should not see a line that
reads:
        tcp  0  0  *.25  *.*  LISTEN
(Well, actually, you *should*, if m-net in fact accepting incoming mail,
but my guess is that you *won't*.) There are two reasons this could
happen, sendmail wasn't run with the right args, or sendmail has decided
the local host is "too busy" to accept mail.  The normal way to have
sendmail receive incoming mail, is to run sendmail with args like this:
        sendmail -bd -q31m
The "-bd" says to go into "daemon" mode, & listen for incomign mail.
The "-q31m" says to process the mqueue directory and do resends, every
31 minutes.  When sendmail runs, it replaces its args with its current
status.  Normally, the process that is accepting connections will say:
        sendmail: accepting connections
If sendmail is rejecting incoming connections, it will say:
        sendmail: rejecting connections: reason
where reason is normally "load average: %d".  (%d will be replaced with
the system load average, according to sendmail's last measurement.) You
can also find other values, such as:
        XAAA23523 coast.net: user open
(a sendmail which is sending mail to another site), or
        running queue: /usr/spool/mqueue
(when it is processing the queue),
        server coast.net cmd read
(a child process, which has accepted a connection from coast.net, and is
currently awaiting a command from there.)

If m-net is still running smail, then the above information on the "ps"
command name will be wrong, and the information on how "sendmail" should
be invoked is probably also incorrect.  The information on "netstat"
will still be correct.  As I recall, smail would normally be invoked
from /etc/inetd.conf, possibly via the tcp wrapper, and would nearly
immediately after invoke smail, possibly with a "-bs" argument.  If the
tcp wrapper is being used, one of the things to check is that the
wrapper is in fact configured correctly, to receive mail from elsewhere.
My guess is that this is not a wrapper problem, from the speed at which
the connection was closed.

One other thing worth mention is that, because m-net has been down so
long, we have put a kludge into *our* sendmail which acts as if there
were a MX record for m-net, directing mail to Mail.coast.net instead.
The reason we've done this is because the extra retries were burdening
grex, and because many of the people who were sending mail either had
return addresses pointing back to m-net, or invalid return addresses,
and so this mail was all bouncing to the grex postmasters, who couldn't
do a thing to fix the problem.  We will probably take this out again, if
mail to m-net ever starts working.  It would be a Good Thing, if m-net
were to add Mail.coast.net (or another reliable site) as a backup mail
MX site.  Until recently, m-net had vela.oakland.edu as a backup site,
but that seems to have disappeared (did oakland get pissed off?)

Marcus, we *believe* M-Net's problems have been fixed.  I'd appreciate
Grex staff monitoring the situation.  If after a few days we're still
"OK," maybe you should consider removing Grex' sendmail kludge.
        Thanx!!

would be nice to be able to get on mnet, it answers but hangs up on ya . .
. .

i had trouble with the patron trunk hunt but was able to log on using the
member hunt.  there were very few users on and i guess the dialup lines
are the cause.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss