how to setup an own freebsd-update server

Hi all!

It's hard to connect to the official update server in my country. Does anyone know how to setup an own one? I have downloaded the freebsd-update-server project and tried to setup one followed by its usage. But what i can't figure out is that who to setup a update web server after uploaded built file to it.
 
freebsd-update(8) is very useful to further understand freebsd-update and how to configure it.

To permanently change the freebsd-update server used edit /etc/freebsd-update.conf and change the server name. Try update2.FreeBSD.org or update3.FreeBSD.org for instances.

To temporally use the [cmd=]-s[/cmd] switch when issuing the freebsd-update command and specify the server name.
 
I've used a own freebsd-update server with own builds in the past.
On your server where have you uploaded the files setup an ssl http server (apache/lighttp).

make the updates available whith this ssl path
example for FreeBSD 7.2 i386
Code:
/7.2-RELEASE/i386/

change in /etc/freebsd-update.conf the lines
Code:
KeyPrint long-SHA256-Key to your KeyPrint
ServerName update.FreeBSD.org to your.ssl.servername

Now your machine can use your own update server.
 
Nice documentation,

maybe you should write a note about not doing the builds on a system which has space CPU/disc and does additional jobs during the update builds.
Reason: this snipped scripts/build.subr

Code:
futurebuildworld () {
        # Turn off ntpd if necessary
        if /etc/rc.d/ntpd status |
            grep -q 'is running'; then
                ntpd_was_running=1
                log "Turning off NTP"
                /etc/rc.d/ntpd stop >/dev/null
        else
                ntpd_was_running=0
        fi

        [color="Red"]date -n `date -j -v+400d "+%y%m%d%H%M.%S"[/color]` >/dev/null
        buildworld $1 FUTUREBUILD
        date -n `date -j -v-400d "+%y%m%d%H%M.%S"` >/dev/null

        # Turn ntpd back on, if appropriate
        if [ ${ntpd_was_running} = 1 ]; then
                log "Turning NTP back on"
                /etc/rc.d/ntpd start >/dev/null
        fi
}
 
I'm sorry, but I really don't understand what you are saying, and your code snippet doesn't make your point any more clear.
 
I'm sorry, but I really don't understand what you are saying, and your code snippet doesn't make your point any more clear.

The reason is really simple, for example say you have server which is not dedicated for a freebsd-update server build machine.
During the day hours it is maybe a internal file/web/print/mail or whatever machine, during the night you use the machine to build updates.

Now start the freebsd-update builds (meanwhile there are running other jobs on the same machine) at some point the freebsd update process stops your time sync set the time to 400 days in the future to build a second run which is later used to compare the results and set the time back after finish (that's exact what the code snipped shows)

Now guess what happened if this machine is primary a mail server?
A mails which arrive during the step
Code:
        date -n `date -j -v+400d "+%y%m%d%H%M.%S"` >/dev/null
        buildworld $1 FUTUREBUILD
will have a date 400 days in the future.

Hope it is now clear why I suggest a remark to use a dedicated machine.
 
Your suggestion is now more clear, and thank you for explaining. That being said, it isn't for me to suggest the environment that people choose to run this software in. If you are building security updates, I believe people should take more precaution and pause for the not only the system they are running it on, but also the hardware and services that are available on that system.
 
johnblue said:
I can see that. Which is why something like this should be maintained here first instead of other places.

If by here, you mean FreeBSD Documentation Project; I wrot an article that is pending a commit to the Documentation Project of FreeBSD, and I would rather put my efforts into maintaining that. If all goes well, it should be committed in the next week or so.

Beyond that, the article is being published in the Feb issue of BSD Magazine.
 
Back
Top