Re: updating source code from updated tarballs
Hi Juan, Juan Miscaro wrote on Mon, Nov 26, 2007 at 08:17:03AM -0500: --- Nick Holland [EMAIL PROTECTED] wrote: Juan Miscaro wrote: --- Ingo Schwarze [EMAIL PROTECTED] wrote: The standard way to handle upgrades is to update the src on the master only, to build new release sets on the master, and to use the official upgrade process to install these new release sets on the clients. That way, none of the clients will ever need source code. You can extend this to cover ports and packages: The standard way to handle port upgrades is to update the ports tree on the master only, to build new binary packages on the master, and to use pkg_add -u on the clients. That way, none of the clients will ever need the ports tree installed. I'm embarrassed to say that I was intending to build my client systems locally. Save yourself time and work, make a release. Well I've done that on the master and used the release to install the client but I didn't think of using release sets to upgrade the client, especially when it becomes a remote system. Not sure how to do that (upgrade via sets remotely). Just unpack the sets? No, download the new /bsd.rd, boot it, select upgrade, and tell it to fetch the install sets from your private server when it asks you where to get the install sets from. Alternatively, burn your self-built install sets onto your own CD and carry them with you when travelling around the field. The whole upgrade process is very similar to the install process, see the coverlet of your official OpenBSD release CD set for a nice example. The ports tree can be useful though. eh. I keep telling myself that, but I hardly ever use it 'cept on a couple machines. Those are usually NOT machines I'm installing packages to. (i.e., I use the ports tree on my management console machines, but on actual production machines, I never use it. I can look at the tree on my machine I'm sitting at, rather than the machine I'm sshed into, find what I need to know, then pkg_add -i whatever...) I don't get it. How did you go from installing from the ports tree to using pre-compiled packages (pkg_add)? As far as i understand Nick, he is basically not using the ports tree at all, except for looking things up. Having the ports tree around on your desktop machine is nice so you can grep /usr/ports/INDEX and /usr/ports/*/*/Makefile when you feel like it. But when i need optional software, i install the binary package from a package repository - either a public mirror or, if needed, my own binary package collection, a private FTP server inside our intranet. My only machine having the ports tree is my build machine. But over there, it is only used to build committed -current ports nor yet available in snapshots, to test uncommitted -current ports found on ports@, to build modified ports i hacked into and to build completely new ports of so far unported software. Juan Miscaro wrote: The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Unless you tell us what you mean by test update (cvs update? which server? which command, exactly?) even guessing is difficult. unanswered important question. I use cvsup to update my sources (to STABLE): [...] Hm, sorry, i'm not really experienced concerning cvsup. Maybe it's quicker than plain cvs, maybe the same argument still applies: Syncing a large tree might take some time, even when it finally turns out not that much of the stuff changed after all. Thanks for your comments. You are welcome, Ingo -- Ingo Schwarze [EMAIL PROTECTED] Serverbetrieb usta.de / studis.de
Re: updating source code from updated tarballs
--- Nick Holland [EMAIL PROTECTED] wrote: Juan Miscaro wrote: --- Ingo Schwarze [EMAIL PROTECTED] wrote: ... The standard way to handle upgrades is to update the src on the master only, to build new release sets on the master, and to use the official upgrade process to install these new release sets on the clients. That way, none of the clients will ever need source code. I'm embarrassed to say that I was intending to build my client systems locally. Save yourself time and work, make a release. Well I've done that on the master and used the release to install the client but I didn't think of using release sets to upgrade the client, especially when it becomes a remote system. Not sure how to do that (upgrade via sets remotely). Just unpack the sets? The ports tree can be useful though. eh. I keep telling myself that, but I hardly ever use it 'cept on a couple machines. Those are usually NOT machines I'm installing packages to. (i.e., I use the ports tree on my management console machines, but on actual production machines, I never use it. I can look at the tree on my machine I'm sitting at, rather than the machine I'm sshed into, find what I need to know, then pkg_add -i whatever...) I don't get it. How did you go from installing from the ports tree to using pre-compiled packages (pkg_add)? The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Unless you tell us what you mean by test update (cvs update? which server? which command, exactly?) even guessing is difficult. unanswered important question. I use cvsup to update my sources (to STABLE): *default release=cvs *default tag=OPENBSD_4_2 *default host=cvsup.no.openbsd.org *default base=/var/cvsup *default prefix=/usr *default delete use-rel-suffix *default compress OpenBSD-ports OpenBSD-src OpenBSD-xenocara [snip] Thanks for your comments. // juan Looking for a X-Mas gift? Everybody needs a Flickr Pro Account. http://www.flickr.com/gift/
updating source code from updated tarballs
I have a 4.2 master system which I intend to use to quickly install new systems. I have rebuilt the master system with updated sources; made the release sets; and made tarballs of /usr/src. I installed a client system with the sets over ftp. All is well. I want to eventually be able to update the client source code once in the field so I unpacked the master tarballs. The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Given that I may have committed a mistake with the creation of the tarball is my method sound? It seems like a typical operation. Comments? // juan Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/
Re: updating source code from updated tarballs
On Sun, Nov 25, 2007 at 10:31:30AM -0500, Juan Miscaro wrote: I have a 4.2 master system which I intend to use to quickly install new systems. I have rebuilt the master system with updated sources; made the release sets; and made tarballs of /usr/src. I installed a client system with the sets over ftp. All is well. I want to eventually be able to update the client source code once in the field so I unpacked the master tarballs. The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Given that I may have committed a mistake with the creation of the tarball is my method sound? It seems like a typical operation. What's an 'update' in this context? And exactly what was doing the downloading? Joachim
Re: updating source code from updated tarballs
--- Joachim Schipper [EMAIL PROTECTED] wrote: On Sun, Nov 25, 2007 at 10:31:30AM -0500, Juan Miscaro wrote: I have a 4.2 master system which I intend to use to quickly install new systems. I have rebuilt the master system with updated sources; made the release sets; and made tarballs of /usr/src. I installed a client system with the sets over ftp. All is well. I want to eventually be able to update the client source code once in the field so I unpacked the master tarballs. The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Given that I may have committed a mistake with the creation of the tarball is my method sound? It seems like a typical operation. What's an 'update' in this context? And exactly what was doing the downloading? I use cvsup to update my sources (to STABLE): *default release=cvs *default tag=OPENBSD_4_2 *default host=cvsup.no.openbsd.org *default base=/var/cvsup *default prefix=/usr *default delete use-rel-suffix *default compress OpenBSD-ports OpenBSD-src OpenBSD-xenocara // juan Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com
Re: updating source code from updated tarballs
On Sun, Nov 25, 2007 at 03:12:09PM -0500, Juan Miscaro wrote: --- Joachim Schipper [EMAIL PROTECTED] wrote: On Sun, Nov 25, 2007 at 10:31:30AM -0500, Juan Miscaro wrote: I have a 4.2 master system which I intend to use to quickly install new systems. I have rebuilt the master system with updated sources; made the release sets; and made tarballs of /usr/src. I installed a client system with the sets over ftp. All is well. I want to eventually be able to update the client source code once in the field so I unpacked the master tarballs. The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Given that I may have committed a mistake with the creation of the tarball is my method sound? It seems like a typical operation. What's an 'update' in this context? And exactly what was doing the downloading? I use cvsup to update my sources (to STABLE): *default release=cvs *default tag=OPENBSD_4_2 *default host=cvsup.no.openbsd.org *default base=/var/cvsup *default prefix=/usr *default delete use-rel-suffix *default compress And was it downloading more files than on your 'master' server? -stable doesn't receive that many updates, but that can still be quite a few files. Joachim -- TFMotD: netstart (8) - command scripts for network startup
Re: updating source code from updated tarballs
Hi Juan, Juan Miscaro wrote on Sun, Nov 25, 2007 at 10:31:30AM -0500: I have a 4.2 master system which I intend to use to quickly install new systems. This does make sense. You do not tell us whether you are using 4.2-stable or 4.2-current. Both are good choices; in any case, make sure you know which one you are using, and stick to it. Also read: http://www.openbsd.org/faq/faq5.html#Flavors I have rebuilt the master system with updated sources; made the release sets; So far, this is standard practice for both -stable and -current. and made tarballs of /usr/src. What are you going to with a src tarball? I suspect you won't need that kind of beast at all. Besides, why are you using the plural tarball*s*? I installed a client system with the sets over ftp. All is well. I want to eventually be able to update the client source code once in the field so I unpacked the master tarballs. Here i'm losing track of what you are doing. I suppose you are referring to your src tarball(s)? I suspect you won't need source code on the client machines. The standard way to handle upgrades is to update the src on the master only, to build new release sets on the master, and to use the official upgrade process to install these new release sets on the clients. That way, none of the clients will ever need source code. The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Unless you tell us what you mean by test update (cvs update? which server? which command, exactly?) even guessing is difficult. In case you are talking about cd /usr/src; cvs up -dP this will take some time, even with a quick network link, using a public mirror in your own country and without many changes. For the above command, five minutes would seem normal even using a 100 Mbit/s internet connection. But probably this whole discussion is moot. I fail to see the point in copying /usr/src to several machines. If you just want to be able to read the source from all machines, you might want to use NFS, possibly in read-only mode. If you really need to copy the source to many machines, you should probably set up your own internal cvs mirror - but what for? Given that I may have committed a mistake with the creation of the tarball Hard to say - you did not tell us the command you used. On the other hand, this is not rocket science. cd /usr/src; tar -czf /tmp/src.tgz . should be sufficient to copy a source tree from one machine to another. is my method sound? It seems like a typical operation. Comments? Part of what you say looks sound and standard, but part of it does not. Yours, Ingo -- Ingo Schwarze [EMAIL PROTECTED] Serverbetrieb usta.de / studis.de
Re: updating source code from updated tarballs
--- Ingo Schwarze [EMAIL PROTECTED] wrote: Hi Juan, Juan Miscaro wrote on Sun, Nov 25, 2007 at 10:31:30AM -0500: I have a 4.2 master system which I intend to use to quickly install new systems. This does make sense. You do not tell us whether you are using 4.2-stable or 4.2-current. Both are good choices; in any case, make sure you know which one you are using, and stick to it. Also read: http://www.openbsd.org/faq/faq5.html#Flavors I have rebuilt the master system with updated sources; made the release sets; So far, this is standard practice for both -stable and -current. and made tarballs of /usr/src. What are you going to with a src tarball? I suspect you won't need that kind of beast at all. Besides, why are you using the plural tarball*s*? I made a tarball of /usr/src and of /usr/ports I installed a client system with the sets over ftp. All is well. I want to eventually be able to update the client source code once in the field so I unpacked the master tarballs. Here i'm losing track of what you are doing. I suppose you are referring to your src tarball(s)? I suspect you won't need source code on the client machines. The standard way to handle upgrades is to update the src on the master only, to build new release sets on the master, and to use the official upgrade process to install these new release sets on the clients. That way, none of the clients will ever need source code. I'm embarrassed to say that I was intending to build my client systems locally. The ports tree can be useful though. The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Unless you tell us what you mean by test update (cvs update? which server? which command, exactly?) even guessing is difficult. In case you are talking about cd /usr/src; cvs up -dP this will take some time, even with a quick network link, using a public mirror in your own country and without many changes. For the above command, five minutes would seem normal even using a 100 Mbit/s internet connection. But why should there be such a change if I just finished updating those same sources on the master? But probably this whole discussion is moot. I fail to see the point in copying /usr/src to several machines. If you just want to be able to read the source from all machines, you might want to use NFS, possibly in read-only mode. If you really need to copy the source to many machines, you should probably set up your own internal cvs mirror - but what for? Actually, the master is inside my company network whereas the clients are remote systems (in the field). [snip] Thanks for the advice. // juan Looking for a X-Mas gift? Everybody needs a Flickr Pro Account. http://www.flickr.com/gift/
Re: updating source code from updated tarballs
Juan Miscaro wrote: --- Ingo Schwarze [EMAIL PROTECTED] wrote: ... The standard way to handle upgrades is to update the src on the master only, to build new release sets on the master, and to use the official upgrade process to install these new release sets on the clients. That way, none of the clients will ever need source code. I'm embarrassed to say that I was intending to build my client systems locally. Save yourself time and work, make a release. The ports tree can be useful though. eh. I keep telling myself that, but I hardly ever use it 'cept on a couple machines. Those are usually NOT machines I'm installing packages to. (i.e., I use the ports tree on my management console machines, but on actual production machines, I never use it. I can look at the tree on my machine I'm sitting at, rather than the machine I'm sshed into, find what I need to know, then pkg_add -i whatever...) The trouble is that when I performed a test update of this code there was a immense amount of downloading taking place. This should not have been the case. Unless you tell us what you mean by test update (cvs update? which server? which command, exactly?) even guessing is difficult. unanswered important question. In case you are talking about cd /usr/src; cvs up -dP this will take some time, even with a quick network link, using a public mirror in your own country and without many changes. For the above command, five minutes would seem normal even using a 100 Mbit/s internet connection. But why should there be such a change if I just finished updating those same sources on the master? Because you either did or expect something wrong. What, we don't know. :) Even with a local CVS repository, a cvs update will take time, as it compares a lot of data. IF you use the right/wrong options, it produces a lot of output, which you may be misinterpreting as changes, even though it was just a progress report. (-q is your friend. usually). If you really are getting large numbers of actual changes, you probably aren't working with a -stable tree. If you didn't intend to, that's life, lots of changes are made to the tree every day. If you did intend to, your process is wrong, because you aren't. :) Nick.
