Running an Old Kernel
I have been attempting to shut off that "last login" message that occurs on some FreeBSD systems every time one runs a sudo command. I decided to bring back the last kernel which was the original Generic kernel from the FreeBSD distribution disk for FreeBSD8.0 to see if the problem went away. If it did, that would indicate that the problem starts after one applies the latest patches and rebuilds the kernel. The handbook covers building a new kernel very well, but I appear to be missing something. In /boot is loader and loader.old. Isn't loader.old the image of the previous kernel? I copied loader to loader.new since it should be the current image and then copied loader.old to loader and rebooted. The "last login" message was still there and dmesg still showed the production date of the new kernel. In other words, nothing changed. Shouldn't I have seen the production date of the original kernel? Thank you. I have actually built many kernels and most were simply a rebuild of the generic kernel after applying patches so I don't roll back a kernel very often. Fortunately, both the old and new kernels work. I think the "last login" nuisance started right after installing the patched kernel. Martin McCormick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Running an Old Kernel
Martin McCormick wrote: > I have been attempting to shut off that "last login" message > that occurs on some FreeBSD systems every time one runs a sudo > command. I decided to bring back the last kernel which was the > original Generic kernel from the FreeBSD distribution disk for > FreeBSD8.0 to see if the problem went away. If it did, that > would indicate that the problem starts after one applies the > latest patches and rebuilds the kernel. > > The handbook covers building a new kernel very well, but > I appear to be missing something. In /boot is loader and > loader.old. Isn't loader.old the image of the previous kernel? I > copied loader to loader.new since it should be the current image > and then copied loader.old to loader and rebooted. > I don't think you've read the sections regarding kernel very carefully. The loader is built and installed as part of buildworld and installworld, not buildkernel or installkernel. It is not the kernel, which is usually installed in /boot/kernel, with the old kernel usually being moved to /boot/kernel.old when a new kernel is installed. > The "last login" message was still there and dmesg still > showed the production date of the new kernel. In other words, > nothing changed. > > Shouldn't I have seen the production date of the > original kernel? Thank you. > > I have actually built many kernels and most were simply > a rebuild of the generic kernel after applying patches so I > don't roll back a kernel very often. Fortunately, both the old > and new kernels work. I think the "last login" nuisance started > right after installing the patched kernel. > Why on earth are you tinkering with your kernels in order to change sudo output? You should instead be editing configuration files associated with sudo and related base system utilities, or patching sudo. b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Running an Old Kernel
On 6/25/10, b. f. wrote: > Martin McCormick wrote: >> I have been attempting to shut off that "last login" message >> that occurs on some FreeBSD systems every time one runs a sudo >> command. I decided to bring back the last kernel which was the ... > Why on earth are you tinkering with your kernels in order to change > sudo output? You should instead be editing configuration files > associated with sudo and related base system utilities, or patching > sudo. I should be more specific: I think you should be able to disable the message by commenting out the lines that refer to pam_lastlog.so in /etc/pam.d/system, /etc/pam.d/xdm, and /etc/pam.d/telnetd. But in doing so, you will lose some of the security and accounting benefits of last(1) and friends. Is it really worth it, just to silence some console messages? In any event, don't tinker with your kernel because of this. It won't help, and it may break your system. b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Running an Old Kernel
"b. f." writes: > Why on earth are you tinkering with your kernels in order to change > sudo output? You should instead be editing configuration files > associated with sudo and related base system utilities, or patching > sudo. Absolutely. I couldn't remember if this happened with the original kernel so I wanted to put it back long enough to see if the problem went away. If it is gone under the original kernel and here with the patched kernel, this might tell me something useful. I have a 8.0 system here that has a patched kernel that is a little older and it does not exhibit that behavior. Sudo is configured exactly the same way on both systems. The environment looks the same. This really makes no sense so there is something different on the system with the problem and I just have not found it yet. Martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Running an Old Kernel
On 6/25/10, b. f. wrote:
> On 6/25/10, b. f. wrote:
>> Martin McCormick wrote:
>>> I have been attempting to shut off that "last login" message
>>> that occurs on some FreeBSD systems every time one runs a sudo
>>> command. I decided to bring back the last kernel which was the
> ...
>> Why on earth are you tinkering with your kernels in order to change
>> sudo output? You should instead be editing configuration files
>> associated with sudo and related base system utilities, or patching
>> sudo.
>
> I should be more specific: I think you should be able to disable the
> message by commenting out the lines that refer to pam_lastlog.so in
> /etc/pam.d/system, /etc/pam.d/xdm, and /etc/pam.d/telnetd. But in
> doing so, you will lose some of the security and accounting benefits
> of last(1) and friends. Is it really worth it, just to silence some
> console messages? In any event, don't tinker with your kernel because
> of this. It won't help, and it may break your system.
Looking at Matthew Seaman's earlier response, I find that his
suggestion to make changes to ${PREFIX}/etc/pam.d/sudo is more
appropriate than my guess above. But you probably need to look into
the details, because judging from the comments in the
${PREFIX}/etc/pam.d/sudo.default file, there seems to be some
subtleties involving sudo and pam_lastlog. Look at the pertinent
manpages, the sudo docs, and:
http://www.freebsd.org/doc/en/articles/pam/index.html
b.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Running an Old Kernel
"b. f." writes:
> On 6/25/10, b. f. wrote:
> Looking at Matthew Seaman's earlier response, I find that his
> suggestion to make changes to ${PREFIX}/etc/pam.d/sudo is more
> appropriate than my guess above. But you probably need to look into
> the details, because judging from the comments in the
> ${PREFIX}/etc/pam.d/sudo.default file, there seems to be some
> subtleties involving sudo and pam_lastlog. Look at the pertinent
> manpages, the sudo docs, and:
>
> http://www.freebsd.org/doc/en/articles/pam/index.html
I do not believe any longer that this has anything to do
with the FreeBSD version or patch level or the kernel. I have
not solved the problem yet, but someone sent me a message off
list with several good suggestions for comparing files on one
system to those on another. I began to test to see which of our
existing systems show the last login message and which do not.
The fortunate thing is that there are several FreeBSD
systems spread out over 3 campuses. All run FreeBSD6.3 at the
same patch level. Three out of the 6 work normally. The other 3
also work normally except for that "last login" message.
The FreeBSD8.0 system that also shows the message is
patterned after one of the systems that is also displaying the
unwanted message.
The 3 systems that show the message are all essentially
copies of each other so I am unwittingly copying the behavior
even across FreeBSD versions.
I expect to find the corruption in /usr/local
as that is the one directory tree in which many files and
scripts from the old system are copied to the new system. I may
be accidentally getting some libraries or some of /usr/local/bin
that should not come across.
I will post a message when I find out because this
behavior should not be happening.
Martin McCormick
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Running an Old Kernel Solved.
There is a /etc/pam.d and a /usr/local/etc/pam.d. /etc/pam.d has no sudo file in it but /usr/local/etc/pam.d does. I had never edited that file before but it seems to change slightly in 2007. The sudo file on the system that did not display the "last login" message has a modification date of December 20, 2007 and sudo, itself also has that date. Here is that file. # # $Id$ # # PAM configuration for the "sudo" service # # auth authinclude system # account account include system # session # XXX: pam_lastlog (used in system) causes users to appear as though # they are no longer logged in in system logs. session requiredpam_permit.so # password passwordinclude system This line makes the difference. # XXX: pam_lastlog (used in system) causes users to appear as though # they are no longer logged in in system logs. This version effectively has no include system directive for that file. The system that did display the "last login" message had a pam.d/sudo file dated July of 2007. /usr/local/bin/sudo had a modification date of April 8 of 2008. I may have removed sudo and reinstalled it to try to get rid of the problem but I obviously did not also get a new /usr/local/etc/pam.d/sudo file which would probably have been the only change necessary. Here is the older file. # # $Id$ # # PAM configuration for the "sudo" service # # auth authinclude system # account account include system # session session include system # password passwordinclude system Here's the big difference. session include system As soon as I commented it out, the problem went away. One needs to be xtremely careful in not restoring the old /usr/local/pam.d directory when building a new system and restoring files from the old system. I have been chasing this monster since the Summer of 2007. The new 8.0 system is presently turned off but I bet when I look at it on Monday, it has the 2007 /usr/local/etc/pam.d directory since I completely forgot about making sure it didn't get in to the new system. Martin McCormick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
