2.0.3 spamming logfile with nsswitch warning

pvoigt

Well, same here. Upgraded yesterday: 2.0.1 -> 2.0.3 (nanoBSD 2G AMD64). Nsswitch message definitely appeared right after upgrade ~27 hours ago:

Sending logfile remotely to syslog server:
grep -i nsswitch pfsense_pfsense |wc -l
1714

Message detail:


Apr 16 19:04:50 pfsense ps: NSSWITCH(_nsdispatch): nis, passwd_compat, setpwent, not found, and no fallback provided

Some details:

No packages.
1x WAN DSL/PPPoE.
3 VLANs on two ethernet devices.
1 ath0 device, 1x cloned.
Some rules to isolate 1 WLAN and DMZ from other networks.
Since today: More detailed egres filtering on all internal devices. nsswitch message, however, was present already without this, e.g. with simpler egres rules.
HW: Jetway NF99FL-525.

Should I provide more details on my setup?

EDIT: Just realized that this nsswitch message cannot be found in the log files on my pfSense box. Are they filtered out? Currently the do appear only in my remotely send syslog file.

svenvelt

Hi!

ATM I changed the remote syslog line of /etc/syslog.conf (-> /var/etc/syslog.conf) via shell access to


#OLD#*.*		@ <ip-of-remote-syslog>*.info 			@</ip-of-remote-syslog>

So no facility "debug" messages should be sent to remote syslog host. Seems to work for me now but I'm not really happy with this :-\

Bye

Sven

pvoigt

@svenvelt:

Hi!

ATM I changed the remote syslog line of /etc/syslog.conf (-> /var/etc/syslog.conf) via shell access to
#OLD#*.*		@ <ip-of-remote-syslog>*.info 			@</ip-of-remote-syslog>
So no facility "debug" messages should be sent to remote syslog host. Seems to work for me now but I'm not really happy with this :-\

Bye

Sven

Thanks, Sven, for this hint. I'll have apply this change to log level because my remote syslog files are growing enormously.

I have no idea, if this nsswitch warning is indicating any severe error. A shot into the dark: I suppose the warning is somehow related to the new openssl version. In a reproducible way e.g. these warnings appear in my remote syslog as soon I ssh into my pfsense machine.

I am currently observing my pfSense machine very carefully. It's running very stable otherwise - thanks to the pfSense team to all the visible and invisible improvements :).

Peter

cmb

Is that showing in the system log, or otherwise which one?

pvoigt

@cmb:

Is that showing in the system log, or otherwise which one?

On my pfsense machine all logfiles under /var/log do not show this nsswitch warning. I only obtain this in the messages which are sent to my remote syslog server.

Remote syslog messages appear to be sent with SyslogLevel ".". I've select "Everything" under "System logs -> Settings -> Remote syslog servers". I conclude from this that those warning messages originate from local SyslogLevels "*.info", e.g. from "auth.info, authpriv.info, daemon.info" in /etc/syslog.conf.

dukecount

I changed the remote syslog line of /etc/syslog.conf (-> /var/etc/syslog.conf) as recommended

from

*.*		@

to

*.info		@

but a subsequent change of the configuration of System logs from GUI undo the change to the file "syslog.conf" restoring the initial situation

pvoigt

@duke:

I changed the remote syslog line of /etc/syslog.conf (-> /var/etc/syslog.conf) as recommended

from
*.*		@
to
*.info		@
but a subsequent change of the configuration of System logs from GUI undo the change to the file "syslog.conf" restoring the initial situation

Well, this could only solved, if the SyslogLevel of remotely sent messages could be adjusted via the webGUI. May be, this would be nice to have, independently of the purpose of suppressing unwanted warnings :). Does anybody know if this feature is implemented in 2.1?

svenvelt

@cmb:

Is that showing in the system log, or otherwise which one?

No, not showing up in system logs. I'm not familiar with FreeBSD's syslog configuration, but I think that no rule will write "*.debug" messages to any file there.

OTOH the default remote rule "." sends ALL messages (including "*.debug") to the syslog host.

Bye

Sven

pvoigt

@svenvelt:

@cmb:

Is that showing in the system log, or otherwise which one?

No, not showing up in system logs. I'm not familiar with FreeBSD's syslog configuration, but I think that no rule will write "*.debug" messages to any file there.

OTOH the default remote rule "." sends ALL messages (including "*.debug") to the syslog host.

Bye

Sven

OK, that's consistent with my observation: May be there is no feedback from others, because pfSense (local) syslog looks the same as before the upgrade to 2.0.3. Only the messages sent to a remote syslog server do show this warning. Could anybody confirm or falsify this observation?

PistolPete

Googled "NSSWITCH(_nsdispatch): nis, passwd_compat, setpwent, not found, and no fallback provided" as I too am getting this since upgrade and found this page.

pvoigt

@dig1234:

I'm on nanoBSD i386. upgrade from 2.0.2 to 2.0.3 was a disaster. Bootup would hang at Starting Firewall.
Turned on verbose logging, eventually bootup finishes but packages did not reinstall.
Getting message in syslog and console: kernel: t_delta 15.fd984de3455432fc too short etc.
Will try installing from scratch, maybe upgrade process just crapped out. Otherwise I'll go back to 2.0.2

Well, these issues are looking even more serious than those nsswitch warnings. Maybe I missed it but are you getting the nsswitch warning besides your other problems? If yes, could you please give feedback I they do disappear after a clean install? I'm runing a NanoBSD image and it is a real pain to exchange CF card for re-imaging.

pvoigt

@PistolPete:

Googled "NSSWITCH(_nsdispatch): nis, passwd_compat, setpwent, not found, and no fallback provided" as I too am getting this since upgrade and found this page.

Inspired by your reply I've re-googled and found some hints that the nsswitch warning might disappear if /etc/nsswitch.conf is changed:
http://www.ivorde.ro/FreeBSD_Cron__NSSWITCH_nss_method_lookup_errors-44.html. The reference made the cron related nsswitch warnings disappear by changing "compat" to "files".

I've too little experience with /etc/nsswitch.conf but would at least like to compare my current settings with a.) pfSense 2.0.1/2.0.2 and with b.) other pfSense 2.0.3 installations. My current 2.0.3 settings are:


group: compat
group_compat: nis
hosts: files dns
networks: files
passwd: compat
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files

Are these settings as expected?

RonpfS

Did a install from scratch of 2.0.3 x86
Restore the configuration from 2.0.1
Packages: Backup, Cron, File Manager, pfBlocker, snort, System Patches, widescreen

I get these 2013-04-25 18:30:00 Cron.Info 172.24.42.254 /usr/sbin/cron[57493]: (root) CMD (/usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_cron_misc.inc)
2013-04-25 18:30:00 Cron.Debug 172.24.42.254 cron[57198]: NSSWITCH(_nsdispatch): nis, passwd_compat, endpwent, not found, and no fallback provided
2013-04-25 18:30:00 Cron.Debug 172.24.42.254 cron[57493]: NSSWITCH(_nsdispatch): nis, passwd_compat, endpwent, not found, and no fallback provided

These are every minutes:
2013-04-25 18:30:28 User.Debug 172.24.42.254 ps: NSSWITCH(_nsdispatch): nis, passwd_compat, setpwent, not found, and no fallback provided

The are only on the remote syslog server, not in the Status/System Logs

jimp

edit /etc/nsswitch.conf and see if setting things to "files" and commenting out the nis bits helps, such as:

group: files
#group_compat: nis
hosts: files dns
networks: files
passwd: files
#passwd_compat: nis
shells: files
services: files
#services_compat: nis
protocols: files
rpc: files

RonpfS

@jimp:

edit /etc/nsswitch.conf and see if setting things to "files" and commenting out the nis bits helps, such as:
group: files
#group_compat: nis
hosts: files dns
networks: files
passwd: files
#passwd_compat: nis
shells: files
services: files
#services_compat: nis
protocols: files
rpc: files

Did that and now the messages are gone ;o)
Thanks :)

pvoigt

@jimp:

edit /etc/nsswitch.conf and see if setting things to "files" and commenting out the nis bits helps, such as:
group: files
#group_compat: nis
hosts: files dns
networks: files
passwd: files
#passwd_compat: nis
shells: files
services: files
#services_compat: nis
protocols: files
rpc: files

Nsswitch warnings immediately disappeared after having applied your changes. Thanks, Jim :).

Although I have some rough ideas about the success of your proposed changes, I would like to understand things a bit more in detail:

1.) Were the original nsswitch.conf settings wrong?
2.) Were the nsswitch warnings serious or could the have been ignored and what did the warnings mean?
3.) Why did pfSense 2.0.1 not show those warnings? I suppose 2.0.1 had the same e.g. original nsswitch.conf settings but cannot verify anymore.

Could you please drop some lines on this?

jimp

@pvoigt:

1.) Were the original nsswitch.conf settings wrong?

Probably, but the way 2.0.1 was built the problem was masked/hidden.

@pvoigt:

2.) Were the nsswitch warnings serious or could the have been ignored and what did the warnings mean?

Harmless log spam.

@pvoigt:

3.) Why did pfSense 2.0.1 not show those warnings? I suppose 2.0.1 had the same e.g. original nsswitch.conf settings but cannot verify anymore.

There was a problem with the way the system was being built up until a week or two before 2.0.3 was released, so options in the build system to disable unneeded components of the base OS were being ignored in some cases. As a side effect of this, OpenSSL wasn't updating/working properly until we fixed it on 2.0.3 and 2.1.

The default nsswitch.conf on FreeBSD 8.1 apparently had the compat & nis bits in it. The default one on 8.3 (used for pfSense 2.1) just had 'files' there. We don't include nor need nis, so leaving it out is OK.

We just didn't catch that error on 2.0.3 in remote syslog before the release. It's a fairly easy fix for those who need it though, manually edit the file or gitsync to RELENG_2_0 to pick it up.

pvoigt

Thank you, Jim, for your explanations making me at least feel a bit wiser :)

RonpfS

Would a system patch be created?

jimp

@RonpfS:

Would a system patch be created?

See the last line of my last post.