Menu
▾
▴
bacula-ryol — Roll Your Own Linux
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(31) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: D. S. B. <bar...@fa...> - 2005-05-15 13:34:03
|
Hello Kern, On Sun, 2005-05-15 at 10:50 +0200, Kern Sibbald wrote: > Now, for point 2, this requires several steps: > > 1. Deciding how we will do rpm restores: > - From ftp repository (or yum repository) > - From CDs that we have built > - From the vendor's CDs > > I would favor the first two, since restoring from the vendors > CDs will be useful only until you apply some updates. I would agree. The original install CDs are of little use a few weeks after they are released. If you use the build_thishost_packages python script it will rebuild all of the installed packages as they exist on the system at the time with the added advantage of including all of the configuration files that you have modified. Those rebuilt packages can then be placed in a repository or on CDs for restore. > > 2. A few enhancements to the rescue scripts to start the > rpm restore process and to manage it -- I can do this over the > next couple of months. > > 3. Make modifications to Bacula so that it can exclude backing up > all the files loaded by the rpms -- the current exclusion uses linear > lists, which will be far to expensive for say 300,000 files loaded by > the rpms, so I'll need to implement a new hash exclusion. This would > be done after release of version 1.38 and is no problem, just a bit of > coding. > > 4. Implement the code that creates an rpm from all the changed rpm files > (conf files) and other files not covered by rpms. I forget the name of > the package, but I think the package that you integrated already does > this. > The script I put together for this is unowned_files.pl which I prototyped in perl but would like to see it done in python. I'm also rethinking the use for this. As it stands now, it will grab all files on the target system which are not "owned" by any rpm package and package them up into a host-specific rpm. The problem I see is that this is an open-ended process and you will continue to accumulate such packages as time goes by because after I do it the first time those files are owned so when I introduce new files to the system I need another rpm. Rather, we should take the capability in the script which builds the list of unowned files (currently saved in the file unowned_filelist) and see if we can't get bacula to read that file in as the fileset for the client. If we can do that then the full restore process simply becomes reinstalling all of the re-created rpm packages and then restoring all other files with bacula. > Where I could use help from you (or anyone else) is on items 1 and 4 to do the > research and make recommendations. > |
|
From: Kern S. <ke...@si...> - 2005-05-15 08:51:09
|
Hello Scott,
Last night I got my Bacula rescue disk booting with a 2.6 kernel -- finally!
Since rescue is no longer under the Bacula source tree, I still have a small
amount of work to do to configure it to automatically create the Bacula FD,
but that I will complete in the next 2 or 3 days.
This means that I would like to pickup where we left off on the Ryol project.
However, there are several important things:
1. I probably won't do too much until after Bacula version 1.38 is release (I
will do somethings though).
2. I'd like to refocus the project from my original idea of building Linux
from source, which the project now does to the ideas that you have proposed.
Namely, I'd like to implement in conjunction with the Bacula rescue disk a
full restore of a system starting from rpms, then terminating with Bacula.
Now, for point 2, this requires several steps:
1. Deciding how we will do rpm restores:
- From ftp repository (or yum repository)
- From CDs that we have built
- From the vendor's CDs
I would favor the first two, since restoring from the vendors
CDs will be useful only until you apply some updates.
2. A few enhancements to the rescue scripts to start the
rpm restore process and to manage it -- I can do this over the
next couple of months.
3. Make modifications to Bacula so that it can exclude backing up
all the files loaded by the rpms -- the current exclusion uses linear
lists, which will be far to expensive for say 300,000 files loaded by
the rpms, so I'll need to implement a new hash exclusion. This would
be done after release of version 1.38 and is no problem, just a bit of
coding.
4. Implement the code that creates an rpm from all the changed rpm files
(conf files) and other files not covered by rpms. I forget the name of
the package, but I think the package that you integrated already does
this.
Where I could use help from you (or anyone else) is on items 1 and 4 to do the
research and make recommendations.
--
Best regards,
Kern
(">
/\
V_V
|
|
From: Kern S. <ke...@si...> - 2005-02-04 14:16:17
|
Hello Scott, This is to let you know that I have just committed a few minor changes to ryol (minor optimization of code) as well as some new files. The ones of importance are: rpmcompare and mvoldrpms The first, rpmcompare, takes a single directory name on the command line and reports all occurrences of rpms that have multiple versions. You have seen this before, but it is now split into an rpmutil.py package and then a few lines of code in the main script. The second script, mvoldrpms, takes two directory names, and if it finds an old package in the first directory, it moves it to the second directory. This is very useful for cleaning out old rpms that you don't want cluttering a directory. Note, on some OSes, a mv across filesystems does not work. Obviously I need to add deloldrpms, but well, that is a bit more dangerous, especially if my comparison screws up -- I'll add it later when we have more experience with mvoldrpms. Note, I do no checking to ensure that the directory names are valid, so it will simply bomb if you make a typo. It *should* cause no harm. -- Best regards, Kern |
|
From: Kern S. <ke...@si...> - 2005-01-14 10:51:36
|
Hello Scott, Well, I've succeeded in doing a full source build with *all* the updates! I've even booted the new 2.6.10 kernel and it works! Hopefully when I get back from vacation, I will have an rpm merge program that will merge all the new rpms into the release directory and remove the old versions. From there I can rebuild the CD set and the first phase of the project will be "complete". -- Best regards, Kern |
|
From: Kern S. <ke...@si...> - 2005-01-13 08:40:49
|
Hello Scott, On Wed, 2005-01-12 at 19:26 -0500, D. Scott Barninger wrote: > Hello Kern, > > I'm modifying the Makefile (and config) to add targets to grab prebuilt > binaries if desired. I can't really see the point of rebuilding a whole > bunch of stock distro packages if you aren't going to change them. So I > figure: > > 1. make init to set things up > 2. wgetbinbase and wgetbinupdates to pull in the stock distro into your > build/rpms directory > 3. any stock packages you wish to modify in some way either modify the > srpm and place in SRPMS or add an rpmoptions file > 4. add any custom packages to SRPMS > 5. make reinit and make build then just builds your changes > > I haven't committed this yet, just attaching for your comments. Yes, this is exactly what I intended. I want to be able to build from source, so started there, but expect to simply download and update the binary rpms most of the time rather than rebuilding. I'd recommend changing your names to: make getsrcbase make getsrcupdates make getbase make getupdates as these names will be easier to remember (at least for me), but this is just a suggestion -- use the names you prefer. The make reinit is a step in the right direction, but it still doesn't get me where I want to be. Basically, I would like to have a number of source and binary "repositories". Currently, it is a bit of a pain to switch just from the srcbase to the srcupdates. What I really would like is something that facilitates that -- the same goes for the binaries, but we are not yet into merging binaries into a new CD set. After I write the merge code (while on vacation), I would like to be able to easily select multiple "repositories" from which to pull the binary updates (e.g. base, updates, kernlocal, kerndag, ...). This might need a small little Python script instead of a Makefile to implement it -- if you have any ideas, let me know. -- Best regards, Kern |
|
From: D. S. B. <bar...@fa...> - 2005-01-13 00:26:47
|
Hello Kern, I'm modifying the Makefile (and config) to add targets to grab prebuilt binaries if desired. I can't really see the point of rebuilding a whole bunch of stock distro packages if you aren't going to change them. So I figure: 1. make init to set things up 2. wgetbinbase and wgetbinupdates to pull in the stock distro into your build/rpms directory 3. any stock packages you wish to modify in some way either modify the srpm and place in SRPMS or add an rpmoptions file 4. add any custom packages to SRPMS 5. make reinit and make build then just builds your changes I haven't committed this yet, just attaching for your comments. |
|
From: Kern S. <ke...@si...> - 2005-01-10 17:44:23
|
Hello Scott, I've modified the build file structure by eliminating build/errors and creating build/errorlogs in its place. This makes it much easier to understand. I've also created a build/failed that will contain the names of all failed builds. Finally, I have modified buildpackages to accept a list of packages to build on the command line. If none are specified, it will build all unbuilt packages as usual. This feature is useful for fixing one or more package at a time: ./buildpackages kernel-2.6.9-1.667.src.rpm will build only the kernel package then stop. You need to do: cvs update ./config xxx.conf make clean make init I've also added a target: "make reinit" that does a re-initialization but taking into account all the packages that are already built. i.e. it rescans your SRPMS directory (which you can change) and for each source rpm that is not already built, it will add it to the unbuilt list so that the next "make" will build it. This way, you can do the following: export SRPMS=xxx make init make SRPMS=yyy make reinit make and it will build all the src rpms in xxx, then build all the ones in yyy. -- Best regards, Kern |
|
From: Kern S. <ke...@si...> - 2005-01-09 19:56:13
|
On Sun, 2005-01-09 at 14:41 -0500, D. Scott Barninger wrote: > On Sat, 2005-01-08 at 23:11 +0100, Kern Sibbald wrote: > > Hello Scott, > > > > This is to let you know that I have implemented the options feature you > > requested for building rpms. To use it, do a "cvs update" then rebuild > > your Makefile; do a "make init" add your options to the build/rpmoptions > > directory that will have been created. I haven't actually added any > > options myself, so there may be some minor problems ... > > > > Other than a typo in the Makefile (correction in cvs) it seems to work > correctly: Yes, thanks for correcting it. In the end, I think we will need to enhance the options quite a lot, as you already noted. One thing might be to add a "generic" option for just the package name. That way, we won't need to modify the majority of the options files each time the version or release changes. Finally now that I eliminated that one file that was blocking everything, I'm making so really good progress in building *all* of FC3. > > sbarn@scott:~> cd /home/ryol-working/ > sbarn@scott:/home/ryol-working> vi sbarn.conf > sbarn@scott:/home/ryol-working> make clean > sbarn@scott:/home/ryol-working> ./config sbarn.conf > sbarn@scott:/home/ryol-working> mkdir /home/SRPMS/temp > sbarn@scott:/home/ryol-working> > mv /home/sbarn/bacula-build/rpms/bacula-1.36.1-2.src.rpm /home/SRPMS/temp/ > sbarn@scott:/home/ryol-working> make init > ./buildinit > 1 srpms found. > sbarn@scott:/home/ryol-working> ls > build config Makefile paths.py sbarn.conf > buildinit kerns.conf Makefile.in paths.pyc unpack_isos > buildpackages kernstodo nosrc2src.pl README > sbarn@scott:/home/ryol-working> cd build/rpmoptions/ > sbarn@scott:/home/ryol-working/build/rpmoptions> ls /home/SRPMS/temp/ > bacula-1.36.1-2.src.rpm > sbarn@scott:/home/ryol-working/build/rpmoptions> touch > bacula-1.36.1-2.src.rpm > sbarn@scott:/home/ryol-working/build/rpmoptions> vi > bacula-1.36.1-2.src.rpm > sbarn@scott:/home/ryol-working/build/rpmoptions> cd ../../ > sbarn@scott:/home/ryol-working> make build > ./buildpackages > Beginning build of 1 packages. > Building bacula-1.36.1-2.src.rpm ... built OK > Build complete. > sbarn@scott:/home/ryol-working> ls build/rpms/ > i586 > sbarn@scott:/home/ryol-working> ls build/rpms/i586/ > bacula-client-1.36.1-2.i586.rpm bacula-rescue-1.36.1-2.i586.rpm > bacula-gconsole-1.36.1-2.i586.rpm bacula-updatedb-1.36.1-2.i586.rpm > bacula-mysql-1.36.1-2.i586.rpm > sbarn@scott:/home/ryol-working> make clean > sbarn@scott:/home/ryol-working> ls build/rpmoptions/ > bacula-1.36.1-2.src.rpm > sbarn@scott:/home/ryol-working> make reset > sbarn@scott:/home/ryol-working> cat > build/rpmoptions/bacula-1.36.1-2.src.rpm > --define "build_su9 1" --define "build_mysql 1" > sbarn@scott:/home/ryol-working> > -- Best regards, Kern |
|
From: D. S. B. <bar...@fa...> - 2005-01-09 19:41:37
|
On Sat, 2005-01-08 at 23:11 +0100, Kern Sibbald wrote: > Hello Scott, > > This is to let you know that I have implemented the options feature you > requested for building rpms. To use it, do a "cvs update" then rebuild > your Makefile; do a "make init" add your options to the build/rpmoptions > directory that will have been created. I haven't actually added any > options myself, so there may be some minor problems ... > Other than a typo in the Makefile (correction in cvs) it seems to work correctly: sbarn@scott:~> cd /home/ryol-working/ sbarn@scott:/home/ryol-working> vi sbarn.conf sbarn@scott:/home/ryol-working> make clean sbarn@scott:/home/ryol-working> ./config sbarn.conf sbarn@scott:/home/ryol-working> mkdir /home/SRPMS/temp sbarn@scott:/home/ryol-working> mv /home/sbarn/bacula-build/rpms/bacula-1.36.1-2.src.rpm /home/SRPMS/temp/ sbarn@scott:/home/ryol-working> make init ./buildinit 1 srpms found. sbarn@scott:/home/ryol-working> ls build config Makefile paths.py sbarn.conf buildinit kerns.conf Makefile.in paths.pyc unpack_isos buildpackages kernstodo nosrc2src.pl README sbarn@scott:/home/ryol-working> cd build/rpmoptions/ sbarn@scott:/home/ryol-working/build/rpmoptions> ls /home/SRPMS/temp/ bacula-1.36.1-2.src.rpm sbarn@scott:/home/ryol-working/build/rpmoptions> touch bacula-1.36.1-2.src.rpm sbarn@scott:/home/ryol-working/build/rpmoptions> vi bacula-1.36.1-2.src.rpm sbarn@scott:/home/ryol-working/build/rpmoptions> cd ../../ sbarn@scott:/home/ryol-working> make build ./buildpackages Beginning build of 1 packages. Building bacula-1.36.1-2.src.rpm ... built OK Build complete. sbarn@scott:/home/ryol-working> ls build/rpms/ i586 sbarn@scott:/home/ryol-working> ls build/rpms/i586/ bacula-client-1.36.1-2.i586.rpm bacula-rescue-1.36.1-2.i586.rpm bacula-gconsole-1.36.1-2.i586.rpm bacula-updatedb-1.36.1-2.i586.rpm bacula-mysql-1.36.1-2.i586.rpm sbarn@scott:/home/ryol-working> make clean sbarn@scott:/home/ryol-working> ls build/rpmoptions/ bacula-1.36.1-2.src.rpm sbarn@scott:/home/ryol-working> make reset sbarn@scott:/home/ryol-working> cat build/rpmoptions/bacula-1.36.1-2.src.rpm --define "build_su9 1" --define "build_mysql 1" sbarn@scott:/home/ryol-working> |
|
From: Kern S. <ke...@si...> - 2005-01-08 22:11:27
|
Hello Scott, This is to let you know that I have implemented the options feature you requested for building rpms. To use it, do a "cvs update" then rebuild your Makefile; do a "make init" add your options to the build/rpmoptions directory that will have been created. I haven't actually added any options myself, so there may be some minor problems ... -- Best regards, Kern |
|
From: Kern S. <ke...@si...> - 2005-01-04 22:27:02
|
Good idea. I'll look into sorting out the details. Do you want to
become a programmer?
On Tue, 2005-01-04 at 17:13 -0500, D. Scott Barninger wrote:
> On Sat, 2005-01-01 at 20:49 +0100, Kern Sibbald wrote:
> > On Sat, 2005-01-01 at 07:57 -0500, D. Scott Barninger wrote:
> > > Hello Kern,
> > >
> > > Another thought - we need to be able to pass customized command line
> > > --defines to rpmbuild on a per package basis, from a configuration file.
> >
> > Yes, I can see the need here. This isn't going to be so simple. I'd
> > suggest that for the moment, if there are any such files, you create
> > a ./buildexceptions script and put them in there, and we call that
> > script just after ./makebuild
> >
> >
>
> OK, at the risk of showing my python ignorance, here goes:
>
> Create a directory ryol/exceptions and add it to paths.py
> In this directory you manually create a file package-1.1.1-1.src.rpm and
> the contents of this file are:
> --define "something 1" --define "somethingelse 1"
>
> Then in buildpackages something like this completely ignorant
> pseudo-code:
>
> def do_packages():
> failcnt = 0
> pkglist = os.listdir(paths.unbuilt)
> ---
> exceptionslist = os.listdir(paths.exceptions)
> ---
> print "Beginning build of %s packages." % len(pkglist)
> for package in pkglist:
> if '.src.rpm' in package:
> ---
> if package is in exceptionslist
> read contents of exceptions/package into exceptions.package
> rpmcmd = rpmcmd + exceptions.package
> ---
>
> errorlog = paths.errors + '/' + package.replace('.src.rpm', '')
> try:
> print "Building " + package + " ... ",
> sys.stdout.flush()
> stat = os.system(rpmcmd + paths.srpms + '/' + package + '
> &>' + errorlog)
--
Best regards, Kern
|
|
From: D. S. B. <bar...@fa...> - 2005-01-04 22:14:08
|
On Sat, 2005-01-01 at 20:49 +0100, Kern Sibbald wrote:
> On Sat, 2005-01-01 at 07:57 -0500, D. Scott Barninger wrote:
> > Hello Kern,
> >
> > Another thought - we need to be able to pass customized command line
> > --defines to rpmbuild on a per package basis, from a configuration file.
>
> Yes, I can see the need here. This isn't going to be so simple. I'd
> suggest that for the moment, if there are any such files, you create
> a ./buildexceptions script and put them in there, and we call that
> script just after ./makebuild
>
>
OK, at the risk of showing my python ignorance, here goes:
Create a directory ryol/exceptions and add it to paths.py
In this directory you manually create a file package-1.1.1-1.src.rpm and
the contents of this file are:
--define "something 1" --define "somethingelse 1"
Then in buildpackages something like this completely ignorant
pseudo-code:
def do_packages():
failcnt = 0
pkglist = os.listdir(paths.unbuilt)
---
exceptionslist = os.listdir(paths.exceptions)
---
print "Beginning build of %s packages." % len(pkglist)
for package in pkglist:
if '.src.rpm' in package:
---
if package is in exceptionslist
read contents of exceptions/package into exceptions.package
rpmcmd = rpmcmd + exceptions.package
---
errorlog = paths.errors + '/' + package.replace('.src.rpm', '')
try:
print "Building " + package + " ... ",
sys.stdout.flush()
stat = os.system(rpmcmd + paths.srpms + '/' + package + '
&>' + errorlog)
|
|
From: D. S. B. <bar...@fa...> - 2005-01-04 22:00:07
|
Hello Kern, I have the full set of suse srpms (with updates) downloaded. sbarn@scott:/home/ryol-working> make init ./buildinit 2577 srpms found. sbarn@scott:/home/ryol-working> make clean /bin/sh: /bin/rm: Argument list too long make: *** [clean] Error 126 sbarn@scott:/home/ryol-working> Perhaps the clean: target should just be: @rm -rf $(BUILDDIR) |
|
From: Kern S. <ke...@si...> - 2005-01-03 22:41:57
|
Hello, Please do a "cvs update". I've changed the handling of the CWD in the xxx.conf files. Then edit your xxx.conf file, and: - Delete the line: CWD=`pwd` (or any other older version of CWD=...) - Change all occurrences of CWD to PWD Then redo: ./config xxx.conf and you should be in business. Perhaps for good measure, compare your xxx.conf against kerns.conf. -- Best regards, Kern |
|
From: Kern S. <ke...@si...> - 2005-01-03 20:40:33
|
Hello, I've now added the code to create the ISO images, and I have booted one up to the first install screen (i.e. kernel booted, and anaconda running). It works. Of course, now we need to see if it can really install the whole thing, and if we can add to and change the files to be installed. Probably at this point, I'm going to stop work on the anaconda installer scripts, and focus on the following items: - Writing a script that will merge updated rpms into the release, and move the old rpms to some holding directory (where you can delete them). - Upgrading the Bacula Rescue CDROM to permit a 2.6 boot. - Implement a first cut of scripts that will reload/install rpms either from a file list, using apt, or yum. -- Best regards, Kern |
|
From: Kern S. <ke...@si...> - 2005-01-03 11:20:55
|
On Thu, 2004-12-30 at 15:28 -0500, D. Scott Barninger wrote: > Hello Kern, > > I mentioned that SuSE is now employing patch rpms. I think this is how > they are producing them (os something similar). > > http://pythonhacker.is-a-geek.net/main/downloads/my_programs/ruks/ Very interesting. I hope it becomes a standard part of rpms. > > http://www.spinics.net/lists/rpm/msg01673.html > > Comments? > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Bacula-ryol mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-ryol -- Best regards, Kern |
|
From: Kern S. <ke...@si...> - 2005-01-02 20:38:34
|
On Sun, 2005-01-02 at 15:09 -0500, D. Scott Barninger wrote: > On Sun, 2005-01-02 at 20:58 +0100, Kern Sibbald wrote: > > > > > > 1. you can create multiple repositories for base, updates, myrpms etc. > > > 2. you can include third party repositories for dependencies. > > > > In principle this wouldn't be too much of a problem to handle for rpm. > > Rpm by itself can't handle dependencies, hence the existence of apt4rpm > and yum. I would imagine that anaconda handles this itself, so if you > don't use anaconda, or apt or yum then you can't do a dependency check > when installing right? Yes, correct. But anaconda does dependency checking, from what I understand, by using the hdlist files (sort of a stripped down rpm db -- I think). In any case, one is starting from an empty system, and my idea was that the list we feed to rpm will be self consistent so there will be no need to do dependency checking. Also, I am a bit skeptical if apt or yum could handle resolving the dependencies for a full install of 1600+ packages. Of course, if we want, I see no problem using apt or yum -- it is just to do dependency checking they will need a network connection, and I would like to have the default restore work with the CD only without the network being up. This will allow a person with one machine to restore it. -- Best regards, Kern |
|
From: D. S. B. <bar...@fa...> - 2005-01-02 20:09:44
|
On Sun, 2005-01-02 at 20:58 +0100, Kern Sibbald wrote: > > > > 1. you can create multiple repositories for base, updates, myrpms etc. > > 2. you can include third party repositories for dependencies. > > In principle this wouldn't be too much of a problem to handle for rpm. Rpm by itself can't handle dependencies, hence the existence of apt4rpm and yum. I would imagine that anaconda handles this itself, so if you don't use anaconda, or apt or yum then you can't do a dependency check when installing right? |
|
From: Kern S. <ke...@si...> - 2005-01-02 19:58:28
|
On Sun, 2005-01-02 at 13:52 -0500, D. Scott Barninger wrote: ... > > > > FYI, apt is available for Fedora 3 at > http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/3/apt/ Interesting. > but I will be interested to look at yum again. I was thinking apt or yum rather than > straight rpm because: I might also look at apt4rpm again too. > > 1. you can create multiple repositories for base, updates, myrpms etc. > 2. you can include third party repositories for dependencies. In principle this wouldn't be too much of a problem to handle for rpm. The problem is that rpm's ftp code doesn't seem to work. I set up a local ftp server here that publishes my whole rpm tree -- base, updates, SRPMS, ... I have no problem accessing it with ftp or with my Browser, but rpm cannot connect. I'm going to look at the anaconda network install and see how that works. -- Best regards, Kern |
|
From: D. S. B. <bar...@fa...> - 2005-01-02 18:53:06
|
On Sun, 2005-01-02 at 17:55 +0100, Kern Sibbald wrote: > On Sun, 2005-01-02 at 10:29 -0500, D. Scott Barninger wrote: > > On Sun, 2005-01-02 at 15:37 +0100, Kern Sibbald wrote: > > > On Sun, 2005-01-02 at 08:07 -0500, D. Scott Barninger wrote: > > > > > > > > > > > I tend to agree. That was the whole point of my local apt server which > > > > holds my additions to the base distribution, but that still requires > > > > reinstall from cd, configure, get all the updates, then reinstall my > > > > customs. > > > > > > > > Actually, if this were combined with the bacula rescue CD then it should > > > > be possible to: > > > > > > > > 1. reinstall software packages from rpms > > > > 2. restore home directory from bacula server > > > > 3. restore /etc directory from bacula server > > > > 3. restore other non-distro directories from bacula server > > > > 4. reboot > > > > > > Yes, this is *exactly* my thought. Apparently rpm works across the > > > network too, so we might have an option to use that feature to pull from > > > a local repository on another machine -- assuming it is fast enough. > > > > > > > Hmm, I think this is coming together in my mind. > > > > Assumptions: you have a server on your network running bacula and apache > > and you have created an apt repository > > (http://www.barninger.com/apt-rpm/index.html). > > > > You build all of your base and add-on rpms using ryol tools and place > > them into your apt repository. When creating a rescue CD for any client > > on your network you do 'rpm -qa > filelist' which gives you a list of > > package-ver-rel with a \n. Replace the \n with '-ix86.rpm' and you have > > a stream of packages. > > Yes. It seems to me that this part normally will be done when creating a > Rescue CD -- or perhaps we should call it a re-install CD. This will > ensure that you get back what was on your system. Alternatively, if this > all works and is as simple as I think, we could allow "importing" the > filelist at install time from the network -- this would allow you to > keep a more current copy on disk on another machine. > > > > > When booting the rescue CD it does or allows you to do: > > 1. mount all of the tools you need in ramdisk on /rescue > > 2. partition the drive > > 3. create and activate swap > > 4. mount disk partitions to / and so forth > > 4. do apt-get install < filelist > > 5. restore other stuff and settings from bacula > > The only modification I would make here is to permit either using yum to > do the install (apt isn't supported by Fedora), and as the default, to > do the install only with rpm. rpm allows a package install by > specifying with an FTP or http URL as well as the standard local disk > install. > > This project seems to be taking a turn I didn't expect, but is fleshing > out to be much better than I expected as well. :-) > > By the way, there is now a gyum Graphical YUM user interface package > available for FC3. It is pretty simple, but much better than a standard > console yum install. Best of all it is written in Python rather than in > the horrible STL C++ as Synaptic is. GYUM is very likely to become my > preferred system update method -- there is even GYUM applet that > notifies you when there are new updates available. > FYI, apt is available for Fedora 3 at http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/3/apt/ but I will be interested to look at yum again. I was thinking apt or yum rather than straight rpm because: 1. you can create multiple repositories for base, updates, myrpms etc. 2. you can include third party repositories for dependencies. Regards, Scott |
|
From: Kern S. <ke...@si...> - 2005-01-02 16:55:33
|
On Sun, 2005-01-02 at 10:29 -0500, D. Scott Barninger wrote: > On Sun, 2005-01-02 at 15:37 +0100, Kern Sibbald wrote: > > On Sun, 2005-01-02 at 08:07 -0500, D. Scott Barninger wrote: > > > > > > > > I tend to agree. That was the whole point of my local apt server which > > > holds my additions to the base distribution, but that still requires > > > reinstall from cd, configure, get all the updates, then reinstall my > > > customs. > > > > > > Actually, if this were combined with the bacula rescue CD then it should > > > be possible to: > > > > > > 1. reinstall software packages from rpms > > > 2. restore home directory from bacula server > > > 3. restore /etc directory from bacula server > > > 3. restore other non-distro directories from bacula server > > > 4. reboot > > > > Yes, this is *exactly* my thought. Apparently rpm works across the > > network too, so we might have an option to use that feature to pull from > > a local repository on another machine -- assuming it is fast enough. > > > > Hmm, I think this is coming together in my mind. > > Assumptions: you have a server on your network running bacula and apache > and you have created an apt repository > (http://www.barninger.com/apt-rpm/index.html). > > You build all of your base and add-on rpms using ryol tools and place > them into your apt repository. When creating a rescue CD for any client > on your network you do 'rpm -qa > filelist' which gives you a list of > package-ver-rel with a \n. Replace the \n with '-ix86.rpm' and you have > a stream of packages. Yes. It seems to me that this part normally will be done when creating a Rescue CD -- or perhaps we should call it a re-install CD. This will ensure that you get back what was on your system. Alternatively, if this all works and is as simple as I think, we could allow "importing" the filelist at install time from the network -- this would allow you to keep a more current copy on disk on another machine. > > When booting the rescue CD it does or allows you to do: > 1. mount all of the tools you need in ramdisk on /rescue > 2. partition the drive > 3. create and activate swap > 4. mount disk partitions to / and so forth > 4. do apt-get install < filelist > 5. restore other stuff and settings from bacula The only modification I would make here is to permit either using yum to do the install (apt isn't supported by Fedora), and as the default, to do the install only with rpm. rpm allows a package install by specifying with an FTP or http URL as well as the standard local disk install. This project seems to be taking a turn I didn't expect, but is fleshing out to be much better than I expected as well. :-) By the way, there is now a gyum Graphical YUM user interface package available for FC3. It is pretty simple, but much better than a standard console yum install. Best of all it is written in Python rather than in the horrible STL C++ as Synaptic is. GYUM is very likely to become my preferred system update method -- there is even GYUM applet that notifies you when there are new updates available. -- Best regards, Kern PS: You may not be aware, but they made significant modifications to the boot process for 2.6 kernels -- the Bacula Rescue CD no longer builds correctly on 2.6 kernels, so I guess I'll need to get busy and fix that. |
|
From: D. S. B. <bar...@fa...> - 2005-01-02 15:48:03
|
On Sun, 2005-01-02 at 15:37 +0100, Kern Sibbald wrote: > On Sun, 2005-01-02 at 08:07 -0500, D. Scott Barninger wrote: > > > > > I tend to agree. That was the whole point of my local apt server which > > holds my additions to the base distribution, but that still requires > > reinstall from cd, configure, get all the updates, then reinstall my > > customs. > > > > Actually, if this were combined with the bacula rescue CD then it should > > be possible to: > > > > 1. reinstall software packages from rpms > > 2. restore home directory from bacula server > > 3. restore /etc directory from bacula server > > 3. restore other non-distro directories from bacula server > > 4. reboot > > Yes, this is *exactly* my thought. Apparently rpm works across the > network too, so we might have an option to use that feature to pull from > a local repository on another machine -- assuming it is fast enough. > Hmm, I think this is coming together in my mind. Assumptions: you have a server on your network running bacula and apache and you have created an apt repository (http://www.barninger.com/apt-rpm/index.html). You build all of your base and add-on rpms using ryol tools and place them into your apt repository. When creating a rescue CD for any client on your network you do 'rpm -qa > filelist' which gives you a list of package-ver-rel with a \n. Replace the \n with '-ix86.rpm' and you have a stream of packages. When booting the rescue CD it does or allows you to do: 1. mount all of the tools you need in ramdisk on /rescue 2. partition the drive 3. create and activate swap 4. mount disk partitions to / and so forth 4. do apt-get install < filelist 5. restore other stuff and settings from bacula PS. 6. configure bootloader |
|
From: D. S. B. <bar...@fa...> - 2005-01-02 15:30:50
|
On Sun, 2005-01-02 at 15:37 +0100, Kern Sibbald wrote: > On Sun, 2005-01-02 at 08:07 -0500, D. Scott Barninger wrote: > > > > > I tend to agree. That was the whole point of my local apt server which > > holds my additions to the base distribution, but that still requires > > reinstall from cd, configure, get all the updates, then reinstall my > > customs. > > > > Actually, if this were combined with the bacula rescue CD then it should > > be possible to: > > > > 1. reinstall software packages from rpms > > 2. restore home directory from bacula server > > 3. restore /etc directory from bacula server > > 3. restore other non-distro directories from bacula server > > 4. reboot > > Yes, this is *exactly* my thought. Apparently rpm works across the > network too, so we might have an option to use that feature to pull from > a local repository on another machine -- assuming it is fast enough. > Hmm, I think this is coming together in my mind. Assumptions: you have a server on your network running bacula and apache and you have created an apt repository (http://www.barninger.com/apt-rpm/index.html). You build all of your base and add-on rpms using ryol tools and place them into your apt repository. When creating a rescue CD for any client on your network you do 'rpm -qa > filelist' which gives you a list of package-ver-rel with a \n. Replace the \n with '-ix86.rpm' and you have a stream of packages. When booting the rescue CD it does or allows you to do: 1. mount all of the tools you need in ramdisk on /rescue 2. partition the drive 3. create and activate swap 4. mount disk partitions to / and so forth 4. do apt-get install < filelist 5. restore other stuff and settings from bacula |
|
From: D. S. B. <bar...@fa...> - 2005-01-02 13:09:40
|
On Sat, 2005-01-01 at 20:56 +0100, Kern Sibbald wrote: > On Sat, 2005-01-01 at 07:27 -0500, D. Scott Barninger wrote: > > Hello Kern, > > > > I added a second wget target to grab update packages and a second source > > for base packages. By the way, both the base and update targets should > > only download a file if it is newer than the local copy, thus you can > > periodically run the update target to get new stuff. > > > > The second base source is because SuSE provides src.rpm and nosrc.rpm > > packages. nosrc packages could be stuff like themes which actually have > > no source code or packages for which they can't deliver source. They are > > a standard srpm with just an install section, no build. > > > > This requires some python changes which I leave to you since I know next > > to nothing here. > > > > 1. do_packages() in buildpackages needs to recognize .nosrc.rpm as well > > as src.rpm. > > I think I have change my mind a bit on this. > > I took a look at the Fedora release and there are no nosrc.rpm files. > I'm not sure what I would like to do. I hesitate, because my first > reaction is that SuSE should not be creating a new extension that seems > to serve no purpose. Until I can understand why it is needed, I'd like > to do nothing. > > In the mean time, I'd recommend that you write a small script (or I'll > write one for you) that simply copies all .nosrc.rpm extensions > into .src.rpm. > > nosrc2src.pl now in cvs. |
|
From: D. S. B. <bar...@fa...> - 2005-01-02 13:08:26
|
Hello Kern, On Sun, 2005-01-02 at 13:37 +0100, Kern Sibbald wrote: > Hello Scott, > > This is just to let you know that I got the last "difficult" part of > building a CD set working. The only remaining tasks now are to make the > ISO image from and burn it, both of which are "trivial". I'll complete > this probably today or tomorrow. Of course, the key part will be to > boot the CD images created. > > Concerning your question about whether it will be possible or worth the > effort to load and build all the RH stuff necessary to run anaconda, I > have two responses: > > 1. Yes, I think it is worth the effort. I'm sure it is possible because > I've seen (pointed to by a user) an anaconda implementation for Debian > that uses apt, ..., but I can understand that it may be a bit too much > -- see my next response. > > 2. I'm going to finish the current path I have made to the point of > being able to create a CD set. However, I think that the future will be > DVDs rather than CDs, so I don't want to spend too much time on CDs. In > addition, though anaconda is probably the best Linux installer, and will > surely become more important in the future, I think it is *way* too > complicated for what I want. > > What I want is a DVD (or a set of CDs) that will restore all my rpms to > the state I was in previously. It occurred to me that I know how to > build a Bacula rescue boot CDROM, and I know how to install rpms while > booted into this system. Why not just create a CD set that has all the > rpms I want, and only those rpms on it, then make a trivial script that > installs them. If we do that, I would have pretty much what I want, and > the work necessary to build the CD set and install the rpms would be > trivial compared to a full anaconda CD set. It would also be less prone > to errors. > > Once I have completed the current work, I'm going to look into doing the > above. > I tend to agree. That was the whole point of my local apt server which holds my additions to the base distribution, but that still requires reinstall from cd, configure, get all the updates, then reinstall my customs. Actually, if this were combined with the bacula rescue CD then it should be possible to: 1. reinstall software packages from rpms 2. restore home directory from bacula server 3. restore /etc directory from bacula server 3. restore other non-distro directories from bacula server 4. reboot |
