www/squid does not shutdown via rc

[Kevin Oberman]

On Wed, Jan 28, 2015 at 6:58 AM, Dr. Peter Voigt <pvoigt at uos.de> wrote:

> On Tue, 27 Jan 2015 11:51:51 +0100
> Marko Cupać <marko.cupac at mimar.rs> wrote:
>
> > On Tue, 27 Jan 2015 07:11:10 +0000
> > Matthew Seaman <matthew at FreeBSD.org> wrote:
> >
> > > On 2015/01/27 03:52, Kurt Jaeger wrote:
> > > > Doesn't installing a custom kernel break freebsd-update ?
> > >
> > > No.  freebsd-update has always supported using a custom kernel.  It
> > > helps if you name your kernel something other than GENERIC, which
> > > you do by creating a modofoed kernel config file
> > > in /usr/src/sys/amd64/conf (or i386 if that's your architecture):
> > > eg.
> > >
> > > % cat FOO
> > > include GENERIC
> > >
> > > ident FOO
> > >
> > > and then add:
> > >
> > > KERNCONF=   FOO
> > >
> > > to /etc/make.conf
> > >
> > > You should also edit /etc/freebsd-update.conf and change the
> > > 'Components' line to remove 'kernel' from the list.
> > >
> > > None of this is absolutely necessary, but it will help you avoid
> > > accidentally ending up with the generic kernel.
> > >
> > > In any case, what you will need to do is rebuild your kernel and
> > > reinstall it any time freebsd-update touches the kernel.  You can
> > > use freebsd-update to maintain the kernel sources, which will pull
> > > in the needed updates to the kernel sources.
> >
> > The timing for this is really unfortunate for me, because I have just
> > re-installed my FreeBSD fleet of some 20 virtual servers without
> > sources included, and I just introduced "binary only" policy (ok I do
> > build my own ports on one server in poudriere, but all other servers
> > use packages).
> >
> > I guess theoretically it is possible to make "kernel build server"
> > which will build custom kernel for distribution to other servers. I
> > am just not sure how will RELEASE userland tolerate STABLE kernel.
> >
> > Does this sound reasonable? Any tips?
> >
> > Thank you in advance,
>
> Thanks to all who contributed to this thread.
>

Sorry for the late response. I've had guests for hte past few days and
simply have not had time to properly address your concerns.

While most of these concerns are not an issue, exactly why gets a bit more
complex. And there are some real issues, but this is an exceptionally
simple case and eliminates most of them. See comments in-line.

>
> @Kevin:
> Your outline of kernel patching procedure is helpful and corresponds
> in most aspects what I have thought so far. I aggree with you that
> patching, building and installing a custom kernel can be managed. And I
> am sure that I can do it.
>
> So getting a custom kernel installed is one thing but keeping your
> system in a manageable way is another. Kurt and Mattew pointed out that
> you want to keep freebsd-update working in a reliable way and this
> obviously needs some manual interaction. Information about it is
> not too easily gathered and answers given here still leave some
> question open to me.
>

It does, but very little. In general, freebsd-update is a binary update
tool. While it does update sources, if they are present, it makes no use of
those sources.

My instructions provided for saving the GENERIC kernel where freebsd-update
will use it instead of the running kernel. /boot/GENERIC is used only be
freebsd-update. It is otherwise unneeded. This does not touch any files
that will normally require merging, which is often the main complication. I
am unsure whether it will require a merge of the modified source files, but
that is easily avoidable renaming /sys/kern/kern_sig.c.orig to overwrite
the patched /sys/kern/kern_sig.c file, returning the sources to their
original condition.
# cp /sys/kern/kern_sig.c.orig /sys/kern/kern_sig.c

This is not really required, but will assure that, from the perspective of
freebsd-update, the system will be entirely unchanged. There is simply no
impact on future updates as there are no changes left.


> I have had a hard time with freebsd-update when upgrading 10.0-RELEASE
> -> 10.1-RELEASE:
>
> https://forums.freebsd.org/threads/segmentation-fault-while-upgrading-from-10-0-release-to-10-1-release.48977/page-2#post-277094
> and I do not want to get even more trouble letting
> freebsd-update confuse my system with a mixture of GENERIC and custom
> kernels ending in a situation where none of them is able to boot.
>
> I have learned that I can advice freebsd-update to not update my kernel
> but am still confused whether it is the version under /boot/GENERIC or
> the one under /boot/kernel. And I would like to know how to tell
> FreeBSD how to boot a certain kernel. All I know so far is that if a
> kernel fails to boot you have to boot into recovery and move kernel.old
> to kernel. Is there a boot menu available with the FreeBSD boot loader
> which would simplify life a lot?
>

The running kernel is in boot/kernel. /boot/GENERIC is not present unless
you create it and, when present, it is used as the kernel which
frebsd-update will patch in the upgrade phase and then install in the
install phase. Actually, the Handbook recommends always keeping a copy of
the GENERIC kernel as /boot/GENERIC. There is no reason not to allow
freebsd-update to update the kernel as it will use /boot/GENERIC and ignore
the running /boot/kernel/kernel.

The only issue is a freebsd-update security patch prior to the release of
10.2 that updates the kernel. To this date there have been none, but it is
certainly a possibility. If that should happen, the kernel will no longer
have these patches and you will need to re-apply them, following the same
instructions. Once 10.2 is released, the patches will no longer be needed.


> Furthermore, installing a custom kernel influcences a subsequent build
> world process in  a way that I do not yet fully understand.
>

This is not really a "custom kernel" as it is usually meant. That usually
implies changes to the kernel config file, not patches to the kernel. It
gets a bit more complex if the patches touch code used in any kernel
modules. If that is the case, the process would involve a couple more
steps, but this patch does not do any such things. This is a very simple
case.

>
> If all above is clarified I could go the way of using a custom kernel.
> But to be honest: I would do it only, because I have just one
> FreeBSD server to mannage this way. The other FreeBSD based servers
> have FreeNAS and pfSense and are managed differently. But if I was an
> administrator with several FreeBSD servers, this would not be a way to
> go.
>

Actually, dealing with multiple systems would be very little more complex
as, once you have the new kernel built, you simply can copy it to
/boot/kernel/kernel on all other systems. Also copy /boot/GENERIC so that
the next freebsd-update will not be impacted. In any case, you won't need
to worry about this.

I will agree that, should you not feel comfortable with doing this, you
should not, but it is a very simple case and is a good way to learn about a
few of the commonly used tools that a system admin may run into on
occasion. I would strongly suggest that you also read the section of the
Handbook that deals with freebsd-update as it may clarify some issues
better than I have. It is at
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html.
It does talk about /boot/GENERIC, which the man page fails to cover.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com