Advice request: Updating 8.1 with a modified kernel

Hi Guys

I want to update my current 8.1 Release build, which I normally do as follows:

To update the ports, I use:
Code:
portsnap fetch update

Then these two commands to apply security patches
Code:
freebsd-update fetch
&
Code:
freebsd-update install

After that I use Dutchdaemons portupdater.sh script.

Then, after following the advice in /usr/ports/UPDATING I run:

Code:
portmaster -a
.


But in this case I have a modified kernel and am hosting 2 jails.

My questions are:

Is it possible to follow the procedure above for the jails as they do not have modified kernels.
&
What is the best process to apply the updates & patches? Preferably without rebooting.




Thanks :)
 
SirDice said:
True. What you can do is temporarily revert to the GENERIC kernel, run freebsd-update and compile a new custom kernel when everything is done.

Yes, but he will still has to go through the build world procedure in order to update his jails. Besides, reverting to GENERIC requires one more reboot, right ?
 
Thanks guys

I knew I would have to use GENERIC for the update of the host but it seems I neglected the fact that all instances use the same kernel. I was hoping I could just patch the jails and restart them without rebooting the whole server. Thankfully I only have a couple lines for ipfw so aside from the reboot it should be relatively stress free :)

Just to confirm, once I have reverted to GENERIC the update of the jails will follow the same procedure as the host?

Thanks again
 
Hello again,

If the updates do not include any kernel patches, would it be safe to simply move the old custom kernel back after the updates? I know rebuilding the kernel is not a hassle but I am trying to streamline it as much as possible as I will need to be doing this every time an update is available.

Thanks for your time :)
 
ghostcorps said:
Hello again,

If the updates do not include any kernel patches, would it be safe to simply move the old custom kernel back after the updates? I know rebuilding the kernel is not a hassle but I am trying to streamline it as much as possible as I will need to be doing this every time an update is available.

Thanks for your time :)
If you revert back to your own old custom KERNEL then you will be running FreeBSD 8.2-RELEASE world binaries on a FreeBSD 8.1-RELEASE KERNEL. Does this sound alright ?

If you need a custom KERNEL then just rebuild one from the new sources.

A few questions:

1) Why do you need a custom KERNEL in the first place ?

2) How do you plan to upgrade your jails ?

George
 
gkontos said:
If you revert back to your own old custom KERNEL then you will be running FreeBSD 8.2-RELEASE world binaries on a FreeBSD 8.1-RELEASE KERNEL. Does this sound alright ?

Thanks for the reply George,

I am not moving up a version but just updating the security patches and ports. I built the server a little while ago but have not kept it up to date. I am being extra cautious because it is now so far behind.

I need the custom kernel because I am using ipfw with jails. I used this as a guide when I set up the jails.

The plan to upgrade the jails is to first update the host with the scripts mentioned above. Once that is fully working, I will run them over the jails.

It seems simple enough. Do you have any suggestions?

Thanks again
D
 
ghostcorps said:
Thanks for the reply George,

I am not moving up a version but just updating the security patches and ports. I built the server a little while ago but have not kept it up to date. I am being extra cautious because it is now so far behind.

So, if I understand correctly you just want to follow your current release to the latest official security update ?
I can't recall the exact version in 8.1, p3 or p4 maybe.

In any case, the procedure is similar with going to 8.2 or 8.3 (will be released in a few weeks)

ghostcorps said:
I need the custom kernel because I am using ipfw with jails. I used this as a guide when I set up the jails.

The plan to upgrade the jails is to first update the host with the scripts mentioned above. Once that is fully working, I will run them over the jails.

It seems simple enough. Do you have any suggestions?

Thanks again
D

You need to compile a custom kernel for ipfw only if you are using NAT. Otherwise it can be loaded as a module.

Now, if you revert to custom kernel, with no ipfw, and you are using NAT for your jails, then your jails will not function. So, be very careful here.

My suggestion is for you to take the path of building world & kernel. I know it might sound scary but in reality it is not.

George
 
gkontos said:
You need to compile a custom kernel for ipfw only if you are using NAT. Otherwise it can be loaded as a module.

Now, if you revert to custom kernel, with no ipfw, and you are using NAT for your jails, then your jails will not function. So, be very careful here.

My suggestion is for you to take the path of building world & kernel. I know it might sound scary but in reality it is not.

George

Thanks George, I am using NAT which I understood to be the only option with ipfw & jails. I had alot of trouble getting it to work in the first place, I don't have the time to try any other configs. If it wasn't a production box it would be a different story but I have a very small window to do the work.

I was planning on using GENERIC during the security updates & then go back to a custom kernel. Are you saying I will need to disable NAT as well as ipfw during this procedure?

When you say build world do you mean upgrading to 8.2/3? If so that is not an option as the host only offers 8.1 as a VPS.

Thanks :)
D
 
ghostcorps said:
Thanks George, I am using NAT which I understood to be the only option with ipfw & jails. I had alot of trouble getting it to work in the first place, I don't have the time to try any other configs. If it wasn't a production box it would be a different story but I have a very small window to do the work.

You only need NAT if you are not assigning routable IPs to your jails. In any other case you don't need it. But I guess this is a different story now.

I understand your concern about down time. So, in your case planning should be the number one factor here for a successful update. Plan ahead for the update and have a roll back scenario available.

ghostcorps said:
I was planning on using GENERIC during the security updates & then go back to a custom kernel. Are you saying I will need to disable NAT as well as ipfw during this procedure?

Yes, if you revert to GENERIC your NAT rules will not function anymore. IPFW will still work but only for packet filtering.

ghostcorps said:
When you say build world do you mean upgrading to 8.2/3? If so that is not an option as the host only offers 8.1 as a VPS.

Thanks :)
D

Yes, the procedure is the same regardless of what version you are upgrading to. You can use freebsd-update to update to the latest security release in 8.1 or to upgrade to 8.2 or 8.3 in a couple of weeks. Similarly this can be done through a build world & kernel procedure.

The only difference is that if you use freebsd-update you will have to revert back to GENERIC. After the update is done then you can build again your custom KERNEL. As long as you understand that while in GENERIC you will not have the option to use NAT with IPFW.

Another thing, you mentioned that your host only offers 8.1 as a VPS. This sounds a bit weird to me. Depending on their virtualization technology, 8.2 should not be a problem. You can always ask them. If they don't then start looking for other options. You don't want to stick with a host like this for a mission critical VPS.

Regards,
George
 
gkontos said:
planning should be the number one factor here for a successful update. Plan ahead for the update and have a roll back scenario available.

Absolutely. Thankfully, being a VPS this is the easy bit :)


gkontos said:
Yes, if you revert to GENERIC your NAT rules will not function anymore. IPFW will still work but only for packet filtering.

That makes sense but I won't need the NAT rules during the procedure as the jails will be stopped while I update the host. I will only turn on ipfw after the update is complete. Hopefully I don't come under attack during that time...



gkontos said:
Another thing, you mentioned that your host only offers 8.1 as a VPS. This sounds a bit weird to me. Depending on their virtualization technology, 8.2 should not be a problem. You can always ask them. If they don't then start looking for other options. You don't want to stick with a host like this for a mission critical VPS.

I thought it was a bit weird too, I am using webair btw. It is entirely self managed so I don't see what difference it would make to them but I expect it is more of a bureaucratic issue rather than a technical one. I expect that until someone takes the time to update their internal documentation they won't officially support it. They could even have updated their support by now, I'll look into this after the update. For now I just want to make this as smooth as possible, I have let it slide for much too long. If I was to do a version update I would probably just build it from scratch, or at least take my time building it separate from the production server.

Thanks again for your time. The update isn't scheduled till the 15th, so I should be well and truly prepared by then :) I'll be back with any issues or a success story!

Regards
D
 
Hi All,

Can I please get a quick confirmation that rolling back to the unmodified kernel is as simple as renaming the /usr/src/kernel to say /usr/src/kernel.CUSTOM and the backup from /usr/src/kernel.old to /usr/src/kernel.

I was about to do it and got a pang of fear that I was missing something. I have disabled ipfw and the NAT rules so there won't be a conflict after the reboot. But I am just not sure enough to bite the bullet :(

Thanks :)
 
Update: I renamed /usr/boot/kernel to kernel.old and the backup I made kernel.GENERIC to kernel. Then commented out these lines in /etc/rc.conf

Code:
gateway_enable="YES"
firewall_enable="YES"
firewall_script="/etc/ipfw.rules"
firewall_type="closed"

But it did not reboot. I rolled back to kernel.old and it was fine. I assume I just need to rebuild the GENERIC kernel, which I am doing now. But I will need to wait a little while for the next window. Can anyone suggest what I may have done wrong?

The only custom lines in conf/kernel are:

Code:
# Firewall Support
options         IPFIREWALL
options         HZ=1000
options         IPDIVERT

Thanks :)
 
gkontos said:
Hi again,

it is all in the handbook! You shouldn't change anything in /usr/src

[CMD=""]# freebsd-update install[/CMD]
[CMD=""]# nextboot -k GENERIC[/CMD]

Thanks George,

The MYKERNEL conf is in /root/kernels/ where it should be :) Sorry for the confusion, I was half asleep when I posted. I have been working off this page and this page in the handbook. My thinking was that I should have been able to treat the unmodded GENERIC kernel as kernel.old and simply roll back to it as advised here.

I'll look over the link and the commands you sent me and see how I go :)

Thanks again! :D
 
Back
Top