Ir al contenido principal

Ralsina.Me — El sitio web de Roberto Alsina

APT Pupil: your own repository


In a pre­vi­ous ar­ti­cle, I ex­plained how APT can im­prove your Fe­do­ra (or sim­i­lar) sys­tem ad­min­is­tra­tion ex­pe­ri­ence. In yet an­oth­er, I ex­plained how to cre­ate your own RPMs with­out much trou­ble.

Well, you can sure­ly see how there is a need for this ar­ti­cle, ex­plain­ing how you can use your own RPMs via AP­T, right?

So, based on the prin­ci­ple that you can't have too much of a good thing, here it is: a (hope­ful­ly) sim­ple guide to build­ing your own AP­T-RPM repos­i­to­ry.

There is al­ready at least one de­cent such guide: It's good!. I will go in­to a lit­tle more de­tail, though.

Target audience

Will you get any­thing from this ar­ti­cle? I think you will if:

  • You are a sysad­min, or play one for your friends and fam­i­ly.
  • You man­age more than one or two Lin­ux sys­tem­s.
  • You use a RP­M-based sys­tem like Red Hat, Fe­do­ra, Conec­ti­va ( maybe Suse or Man­drake)
  • You like to use APT
  • You in­stall some soft­ware from out­side the usu­al APT repos­i­to­ries, ei­ther cus­tom or self­-­pack­aged.
  • You are not fa­mil­iar with repos­i­to­ry man­age­men­t.

This is not for you (ex­cept by chance), if you fit any of the fol­low­ing cri­te­ri­a:

  • You use a source-based dis­tro
  • You use a De­bian-based dis­tro (the set­up of the re­po is slight­ly dif­fer­en­t)
  • You man­age a sin­gle sys­tem
  • You don't like APT
  • You don't build your own soft­ware or pack­ages

Why your own repo?

Uni­for­mi­ty is one of the ba­sic prin­ci­ples of soft­ware man­age­men­t. If you want to low­er the work in­volved in man­ag­ing mul­ti­ple sys­tem­s, you should try to in­stall soft­ware as sim­i­lar as pos­si­ble in all of them.

To do that, a de­cent sys­tem of soft­ware de­liv­ery is nec­es­sary, so in­stalling the new ver­sions or new pack­ages in all sys­tems is not a hard chore. I like AP­T. But, like all repos­i­to­ry-based sys­tem­s, it has the weak­ness that, if you in­stall some­thing that's not in your re­pos, you are out­side the sys­tem.

Sure, you can just opy the RPMs to each serv­er and in­stall it, but that's what APT is for. The sim­plest so­lu­tion is just build­ing your own re­po, and han­dle it like the rest of the stuff you in­stal­l.

And the most im­por­tant rea­son: it's easy. So easy that even if it gives on­ly a small ben­e­fit, it's still worth it.


You will need sev­er­al things, in­clud­ing:

  • A web serv­er
  • Some apt tools for repos­i­to­ry man­age­ment
  • Some RPMs

The web server

We'll build a HTTP-based repos­i­to­ry. The rea­son is sim­ple: it's usu­al­ly eas­i­er and safer to build a HTTP serv­er than a FTP serv­er.

Please no­tice that I act as if you own the web serv­er. If you don't, just do all this in your own box, and then up­load all the repos­i­to­ry in­to the web­serv­er. That works just fine, and has the added ben­e­fit that the web serv­er is Some­body Else's Prob­lem (TM pend­ing).

If you know Apache, and are hap­py with our Apache se­tup, then just use it. How­ev­er, us­ing such a com­plex piece of soft­ware just for a re­po is ex­treme overkil­l.

If you are start­ing from scratch, and you ex­pect to use the serv­er on­ly for AP­T, and you don't ex­pect it to have high traf­fic, then you can do just as well us­ing a very sim­ple HTTP serv­er.

These fea­tures are use­ful, how­ev­er:

  • Ranges: This al­lows the serv­er to han­dle con­tin­u­a­tion of down­load­s, and may save lots of time.
  • Pipelin­ing: Again, this may help per­for­mance.
  • Down­load rate lim­it­ing: So it does­n't kill you if a mil­lion guys link to it un­ex­pect­ed­ly.
  • A good se­cu­ri­ty his­to­ry
  • Ac­tive­ly main­tained
  • Sim­ple con­fig­u­ra­tion

And, most im­por­tan­t: Make it sim­ple. I am a fetichist of sim­ple soft­ware. All these fea­tures are NOT use­ful for this job:

  • PHP sup­port
  • CGI sup­port
  • Vir­tu­al hosts

All you need to han­dle with this web­serv­er is fetch­ing files. Maybe a di­rec­to­ry list­ing, if you en­ter man­u­al­ly. Al­most ev­ery web­serv­er is mas­sive overkil­l.

The bad news is, there are hun­dreds of web servers you can use, and I know very few of them.

What do I rec­om­mend? Well, I use Apache my­self ;-) But here are a few pos­si­ble ca­di­dates, which I don't en­dorse in any way.

  • Thy: Maybe too fea­ture­ful (and lit­tle known?).
  • thttpd: Looks nice.

And many oth­er­s, like Boa. Even KDE's KPF can work in a hur­ry.

How­ev­er, this ar­ti­cle is not about cre­at­ing a web­site, so the ac­tu­al task of pub­lish­ing a site is left as an ex­er­cise.

The APT repository tools

They came with APT for me, so, if you are us­ing APT in your sys­tem, you should have them too.

To check it, see if you have gen­basedir in­stalled, like this:

[ralsina@roberto ralsina]\$ which genbasedir

If in­stead of giv­ing you a path it gives an er­ror, then you don't have it.

Some RPMs

Al­most any­thing will do. You may, for ex­am­ple, just use all the RPMs from your dis­tro's CD set. That way, you can in­stall them with­out search­ing on what CD they are ;-)

Configuring the repository

A APT repos­i­to­ry is a di­rec­to­ry struc­ture con­tain­ing the RPM­s, plus some ex­tra data­base files cre­at­ed us­ing the APT tool­s.

The directory structure

Split your RPMs in a nat­u­ral way, if need­ed. For ex­am­ple, you may have test­ed and untest­ed RPM­s, or cus­tom (the ones you made) and os (the ones that came with the dis­tro). What­ev­er split you make, makes no dif­fer­ence, re­al­ly. I will use sta­ble and un­sta­ble in the ex­am­ple.

If you use dif­fer­ent dis­tri­bu­tions or ar­chi­tec­tures, that mat­ters too. I use on­ly Fe­do­ra and on­ly i386, but for the ex­am­ple, I will pre­tend to use Red Hat 9 (rh9) and Fe­do­ra Core 2 (fc2).

Now, go to a di­rec­to­ry you share through your web­serv­er and cre­ate some­thing like this:

mkdir -p rh9/RPMS.stable
mkdir -p rh9/RPMS.unstable
mkdir -p fc2/RPMS.stable
mkdir -p fc2/RPMS.unstable
mkdir -p rh9/SRPMS.stable
mkdir -p rh9/SRPMS.unstable
mkdir -p fc2/SRPMS.stable
mkdir -p fc2/SRPMS.unstable

As you can see: a di­rec­to­ry for each ar­chi­tec­ture-dis­tro you sup­port, and in­side it, a RPMS and SRPMS fold­er for each set of RPM­S. you want to dis­trib­ute.

If you are not dis­tribut­ing SRPM files (why not?) you can skip those.

Now, put your .rpm files in the RPMS di­rec­to­ries, your .s­r­c.rpm files in the SRPMS di­rec­to­ries.

Generating the database files

This is what makes this site a APT re­po in­stead of just a bunch of RPMs on a page.

genbasedir --progress --flat --bz2only /whatever/rh9
genbasedir --progress --flat --bz2only /whatever/fc2

Just to be sure: the di­rec­to­ry you pass as ar­gu­ment is the one where the RPM­ you cre­at­ed be­fore is. Af­ter you run gen­basedir, you will have a base/ di­rec­to­ry there.

You need to re­peat this when­ev­er you add or re­move files to your repos­i­to­ry.

Using your repository

First, read this oth­er ar­ti­cle ;-) Specif­i­cal­ly, this part.

In the ex­am­ple set­up I'm do­ing, as­sum­ing my web­serv­er is at http://my­serv­er.­com and that the rh9 and fc2 di­rec­to­ries I cre­at­ed can be seen as http://my­serv­er.­com/ap­t/rh9 and http://my­serv­er.­com/ap­t/fc2, the sources.list file should con­tain this:

#If you are using Fedora Core 2
rpm apt/fc2 stable unstable

#If you are using Red Hat 9
rpm apt/rh9 stable unstable

No­tice how the RPMs are in places like http://my­serv­er.­com/ap­t/rh9/RPM­S.sta­ble and the sources line is sim­ply a chopped up ver­sion of the URL.

Of course you can choose to use on­ly sta­ble (or on­ly un­sta­ble ;-).

Coming up eventually

While APT is all fine and dandy for what it does, in or­der to do re­al­ly good pack­age man­age­men­t, it's not enough to just do ap­t-get up­date and ap­t-get up­grade ev­ery once in a while.

You need to know how to choose a spe­cif­ic ver­sion of a pack­age, and how to pre­vent un­ex­pect­ed up­grades that can break down your con­fig­u­ra­tion.

So, if I ev­er have the time and en­er­gy, I should write an­oth­er ar­ti­cle cov­er­ing pol­i­cy, pin, and oth­er less-pop­u­lar pieces of AP­T.

But that's an­oth­er sto­ry.

Final Words

Hope you en­joyed the ar­ti­cle. If you did, there's more in the Ar­ti­cles sec­tion of the site.

If you have any doubt or ques­tion about any of this, just post a com­ment or email me. The best thing is prob­a­bly to post a com­ment and email me telling me you post­ed it

Roberto Alsina / 2006-04-04 16:33:

Comments for this story are here:

employment background check / 2011-12-27 23:24:

Hi very nice article

Contents © 2000-2024 Roberto Alsina