| 01:10.20 | *** join/#fredlug jsmith_ (n=jsmith@000-200-882.area3.spcsdns.net) |
| 01:10.40 | *** join/#fredlug quigleymd (n=Matt@c-71-62-130-185.hsd1.va.comcast.net) |
| 01:49.07 | *** part/#fredlug quigleymd (n=Matt@c-71-62-130-185.hsd1.va.comcast.net) |
| 02:24.30 | plarsen | how come the good old 'Imap' and 'pop3' xinetd services are totally gone? |
| 02:25.58 | plarsen | ehh - from Centos that is ;) I'm still waiting to get a chance to really play with FC7 |
| 02:54.00 | jsmith | Imap and pop3 are served up by Dovecot |
| 02:54.03 | jsmith | (not from xinetd) |
| 03:26.59 | plarsen | it is now :) |
| 03:27.17 | plarsen | It wasn't on my servers up till now ... FC4 even had it from xinetd |
| 03:27.34 | plarsen | Must admit I miss my xinetd - why it needs to be loaded constantly is a mystery to me |
| 11:58.17 | *** join/#fredlug plarsen_ (n=plarsen@c-24-125-211-129.hsd1.va.comcast.net) |
| 12:47.27 | *** join/#fredlug jsmith (n=jsmith@000-236-848.area3.spcsdns.net) |
| 13:14.38 | *** join/#fredlug quigleymd (n=Matt@24-53-142-3-st.chvlva.adelphia.net) |
| 13:38.14 | *** join/#fredlug jsmith (n=jsmith@000-236-848.area3.spcsdns.net) |
| 13:47.41 | *** join/#fredlug quigleymd (n=Matt@24-53-142-3-st.chvlva.adelphia.net) |
| 14:24.24 | *** join/#fredlug jsmith_ (n=jsmith@h46057329.area3.spcsdns.net) |
| 17:09.47 | plarsen | Where can I read/learn the niddy griddy details of yum repositories?? |
| 17:12.27 | stickster_work | I think there's some info on this at docs.fedoraproject.org |
| 17:13.27 | stickster_work | But basically, you can just use rsync to mirror an existing repo, or reposync for that matter |
| 17:13.37 | stickster_work | To make one from scratch, get the createrepo package and use the createrepo command |
| 17:13.50 | stickster_work | That creates all the XML metadata you need |
| 17:14.11 | plarsen | stickster_work: Well, let me explain ... I've done that, but it was more or less trial and error. I'm trying to figure out what actually is inside the repository so I can sync up with the URL etc. on the client side. |
| 17:14.31 | stickster_work | Are you using rsync? |
| 17:14.40 | plarsen | stickster_work: I found that arch and version was used sorta wierd, and caused bad paths to be generated. |
| 17:14.43 | plarsen | rsync isn't the issue |
| 17:14.52 | plarsen | it's getting TO the repository from the local clients. |
| 17:14.54 | *** join/#fredlug quigleym1 (n=Matt@24-53-142-3-st.chvlva.adelphia.net) |
| 17:15.19 | stickster_work | plarsen: Can you be more specific? |
| 17:16.07 | plarsen | stickster_work: hmmm - I'll try :) I have about 10-15 "boxes" that I don't want RedHat to send the same frigging updates too all the time (work). |
| 17:16.22 | plarsen | I'm setting up a local RedHat ES repository with yum - and I need to configure the clients to get to it. |
| 17:16.38 | stickster_work | Ah, in that case, you just drop a .repo file into /etc/yum.repos.d/ |
| 17:16.41 | plarsen | stickster_work: My problem when I did this for Fedora/CentOS was that I kept getting the path into the repostiroy wrong |
| 17:17.01 | stickster_work | The path you give is the path to the directory that *contains* the "repodata/" folder |
| 17:17.03 | plarsen | stickster_work: I either generated the repostiroy in the wrong directory or had the clients yum.conf use the wrong path in. |
| 17:17.06 | stickster_work | Not the repodata folder itself |
| 17:17.35 | stickster_work | You should generate the repodata folder in an area that is specific to the platform release and the HW arch |
| 17:17.43 | stickster_work | so, e.g. RHEL 4 ES and i386 |
| 17:17.47 | plarsen | And I was simply trying to finda place to learn about this, without bugging others with my lack of knowledge of yum repostiories |
| 17:17.53 | stickster_work | man yum.conf |
| 17:18.11 | stickster_work | That page has all the info about yum repositories... but you can get most of what you need right out of an existing .repo file |
| 17:18.32 | plarsen | stickster_work: That's what I tried initially with fedora/centos - but that really didn't work (for me). I'm sure I did a mistake, I finally got it working without version/arch |
| 17:18.53 | plarsen | I'll go studying some more then :) |
| 17:19.31 | stickster_work | I generate repodata for instance in my mirror's /var/ftp/pub/linux/addons/fedora/6/i836/ folder |
| 17:19.41 | stickster_work | For local packages I distribute here |
| 17:19.50 | stickster_work | sorry, s@i836@i386@ |
| 17:19.52 | plarsen | But do you generate ONE repostiory for ALL distributions or do you have one per "release" ? |
| 17:20.00 | stickster_work | No, it should always be one per release & HW arch |
| 17:20.04 | plarsen | lol - that's ok, I got it. |
| 17:20.12 | plarsen | AHH - that may be where I errored then. |
| 17:20.16 | stickster_work | So if you support i386, x86_64, and PPC, it would be three separate repos -- for *that* Linux distro |
| 17:20.25 | stickster_work | If you support Fedora 5 and 6, that would be 6 total repos |
| 17:20.38 | plarsen | So the 'repodata' directory gets created in the root of the rsync destination? |
| 17:21.17 | stickster_work | Well, ideally it should be in the directory that contains the RPMs, or that contains a directory containing the RPMs |
| 17:21.35 | plarsen | ??? This is my confusion |
| 17:21.47 | stickster_work | Look at an existing mirror on the net. |
| 17:21.50 | plarsen | How does the repository relate to the URL when fetching the packages? |
| 17:22.01 | stickster_work | That depends on your server config ;-) |
| 17:22.11 | plarsen | ARGH!! :) hehe |
| 17:22.36 | plarsen | Do you point httpd to the RPMS directory or the rsync root? |
| 17:22.38 | stickster_work | e.g. http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/ -- that's the top of the base FC6 distribution, contains a directory called Fedora/ which has RPMs in it, also contains repodata/ |
| 17:22.48 | stickster_work | You point it at the directory that *contains* the "repodata/" folder |
| 17:23.03 | stickster_work | So in the example above, you would point to |
| 17:23.08 | plarsen | So the RPMS (or Fedora) |
| 17:23.15 | stickster_work | No. |
| 17:23.27 | stickster_work | To the directory that contains the repodata/ folder. |
| 17:23.38 | stickster_work | In the above example, http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/ |
| 17:23.43 | stickster_work | That's the folder you point to. |
| 17:23.46 | stickster_work | It contains the repodata/ folder. |
| 17:23.53 | stickster_work | That's what should go in the "baseurl=" call in your .repo file. |
| 17:24.07 | stickster_work | Look at the configuration of your existing Fedora machine. |
| 17:24.15 | stickster_work | (or RHEL/CentOS 5) |
| 17:24.20 | stickster_work | (or CentOS 4.x) |
| 17:24.48 | plarsen | uhmmm - but this means that the reposdata/ isn't located in the directory of the rpms, but in it's parent directory? |
| 17:25.27 | stickster_work | When createrepo is run, it searches recursively under the target directory for RPMs |
| 17:25.28 | plarsen | The baseurl points to the folder that has the repodata folder. Got that |
| 17:25.44 | stickster_work | So they can be one, two, ..., N directories down |
| 17:25.47 | stickster_work | Doesn't matter. |
| 17:25.54 | stickster_work | All that matters is that they stay there |
| 17:26.07 | plarsen | So I need one for base, and one for updates? |
| 17:26.20 | stickster_work | You should have one for each repository that needs to be consulted |
| 17:26.25 | stickster_work | so basically, yes |
| 17:26.32 | stickster_work | You can have as many as you want. |
| 17:26.46 | stickster_work | The client is responsible for polling them all and resolving the numbers properly |
| 17:26.51 | plarsen | :) Ok. I'll give it a try tonight. Right now Mr. Doc is calling, so I'm going offline ... thanks for the info. |
| 17:26.56 | plarsen | I'll be playing with it tonight. |
| 17:27.14 | plarsen | Btw. I'm setting up a redhat with up2date and not rsync for redhat stuff. But I hope that won't totally mess things up here. |
| 17:27.16 | plarsen | Take care. |
| 17:27.46 | stickster_work | u2 |
| 17:42.47 | quigleymd_work | now, yum isn't smart enough to pick the fastest mirror, is it? You'll want to remove the existing updates repo, right? |
| 18:26.35 | plarsen_away | quigleymd_work: You sync the updates repository too. |
| 18:30.09 | *** join/#fredlug jsmith (n=jsmith@h4605bb04.area7.spcsdns.net) |
| 20:08.57 | quigleymd_work | plarsen_away: yea, but i mean on the clients that you want to use the locally sync'd repos, you have to manually remove the original, correct? |
| 20:11.06 | plarsen | quigleymd_work: depends on what you need. If there's no update to a package, and a client tries to do an install, then you need the base. |
| 20:11.12 | plarsen | quigleymd_work: In essense, you need both |
| 20:11.23 | plarsen | Some seem to argue to include "extras" and all the other stuff too |
| 20:11.41 | quigleymd_work | understood |
| 22:10.57 | *** join/#fredlug jsmith-away (n=jsmith@000-192-364.area3.spcsdns.net) |