new BIND in 10.0_RC5/sparc dies w/Bus error
Apologies for the poor formatting as I'm having to use my ISP's webmail system. I recently updated my name/dhcp/mail sever to 10.0_RC5. This is a SPARCserver 5 w/256MB RAM. When incoming mail stopped being delivered, I checked the server's maillog and saw that it was rejecting mail due to being unable to resolve the senders' domains. Sure enough, 'named' wasn't running. Checking the logs found that some options in "named.conf" were no-longer available. Commenting those out and restarting, 'named' seemed to finish initialisation and begin running, but the saved PID in "/var/run/named/named.pid" was never in the output of 'ps ax'. Running 'named' in the foreground with: $sudo named -u named -t /var/chroot/named -f would run for a short time, then exit with "Bus error". Unfortunately there was no core dump. Has anyone else seen anything similar with the new BIND in -current and since pulled up to 10.0_RC5? Thanks. -- John D. Baker
Re: mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
I've had a couple of responses to this with some questions about
my setup.
When last working, the system was running NetBSD/sparc-9.1_STABLE from
about:
Thu Mar 11 11:44:19 CST 2021 9.1_STABLE
With all packages built from pkgsrc-2020Q4.
There was a hiccup around mid-March when my ISP up-degraded their mail
system without notice and changed the SMTP-AUTH mechanism, so I had to
probe it to find out what was now being accepted. I added the
appropriate cy2- plugin and mail was again being sent.
I don't know if it was simply coincidental or not, but only after
updating with a netbsd-9 after the OpenSSL pull-up did mail stop
being relayed. The libcrypto and libssl versions didn't change with
the update/pull-up.
I've now looked at things with 'tcpdump -i port submission'
and now I see 'sendmail' talking to a machine that is NOT my ISP's
customer-facing outbound MTA--albeit a machine in the same domain as
that which responds when the actual MTA is contacted. It seems to try
to send stuff--as the files in "/var/spool/mqueue" increase, there's
more
'tcpdump' output when I run 'sendmail -q', but the mail remains queued
and not sent. No additional messages appear in "/var/log/maillog".
Trying to specify the "SMART_HOST" by IP address doesn't work--it still
contacts the same wrong machine. Trying to manually probe the wrong
host with 'telnet foo submission' or
'openssl s_client -connect foo:submission' times out.
And I just did a series of DNS queries and there may be something weird
going on. Forward query for the ISP's MTA returns an IP address, but
the
reverse query ('dig -x ip-addr') returns the name of the "wrong" machine
and forward query of the "wrong" machine yields a different IP address.
So, what I was seeing in the logs was sendmail talking to the correct
machine, but 'tcpdump' resolving the name to the wrong host and my
probes
of the wrong host would naturally fail.
My build has finished so I'll update again and see what happens.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
mail/sendmail not relaying on netbsd-9/sparc, problem with OpenSSL update?
Pardon the poor or utter lack of formatting, I'm having to use
my ISP's webmail system to send this, due to the problem in the
Subject: line.
After updating my mail hub to the latest NetBSD/sparc-9.1_STABLE
including the OpenSSL update and the fix to silence the "coprocessor
instruction" console SPAM, I find that my sendmail (mail/sendmail
v8.15.2nb9) is no-longer relaying mail out of my system.
It accepts mail from my internal hosts (set up as mostly-null clients)
and queues it in "/var/spool/mqueue" but never attempts to contact my
configured SMART_HOST. There's nothing in any log files that indicates
any problem, it just doesn't follow through on relaying outbound mail.
Attempting to forcibly flush the queue with 'sudo sendmail -q' has no
effect.
The only relevant change between working and not working was the update
of OpenSSL pulled up to netbsd-9. I'm using packages from pkgsrc
immediately prior to the roll-back of glib2 from 2.68 to 2.66 (just as
a reference of the state of packages). There were no changes to
"mail/sendmail", "security/cyrus-sasl", or "security/cy2-{login,plain}".
I've cloned my netbsd-9 tree and rolled back the OpenSSL update (only,
prior to 27-Mar-2021 14.35 UTC) and am building the distribution and
sets. Once I update the mail hub from that, I'll see if sendmail will
go ahead and relay.
Anyone else using "mail/sendmail" and seeing anything similar? (Since
my ISP's customer-facing outbound MTA requires authentication,
"security/cyrus-sasl" and an appropriate authentication plugin are also
used.)
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: kern/54289 hosed my RAID. Recovery possible?
On 2019-08-15 00:03, jdba...@consolidated.net wrote: The SiI3214 SATALink card suffers from the identify problem in netbsd-9 and -current (PR kern/54289). Booting a netbsd-9 kernel, the drives failed to identify which caused RAIDframe to mark the 4 drives on that card (of 8) in my RAID as FAILED. Rebooting netbsd-8, the drives identify properly, but are still marked as FAILED. Is there any way to unmark them so the raid will configure and recover? Normally 'raidctl -C' is used during first time configuration. Could it be used to force configuration, ignoring the FAILED status? Would the RAID be recoverable with parity rebuild afterwards? This seems to have worked. The disks not being correctly identified/attached under netbsd-9 apparently had them recorded as failed on the components that did attach (on the machine's on-board intel ahcisata ports). Rebooting netbsd-8, although the drives identified and attached properly, they were still considered failed components. Being a multiple-disk failure is usually fatal to a RAID, but the components weren't actually failed. Un-configuring with 'raidctl -u' then forcing a config with 'raidctl -C /path/to/config' did not show any fatal errors and subsequent 'raidctl -s' showed all component labels (w/serial number) intact. Parity rewrite took a long time. Afterwards, 'gpt show raid0d' and 'dkctl raid0d listwedges' showed things to be intact that far. Rebooting the machine, the RAID properly autoconfigured. 'fsck' reported the filesystem as clean (since it never got mounted after the failed reboot into netbsd-9). An 'fsck -f' run is in progress. John D. Baker
kern/54289 hosed my RAID. Recovery possible?
The SiI3214 SATALink card suffers from the identify problem in netbsd-9 and -current (PR kern/54289). Booting a netbsd-9 kernel, the drives failed to identify which caused RAIDframe to mark the 4 drives on that card (of 8) in my RAID as FAILED. Rebooting netbsd-8, the drives identify properly, but are still marked as FAILED. Is there any way to unmark them so the raid will configure and recover? Normally 'raidctl -C' is used during first time configuration. Could it be used to force configuration, ignoring the FAILED status? Would the RAID be recoverable with parity rebuild afterwards? Thanks. John D. Baker Sorry for the poor (or lack of) formatting. I've had to evacuate to my ISP's web mail until this is sorted out (or I get my "oil lamps" in place).
