Empty primary.xml.gz after changing an alias
87 views
Skip to first unread message
Steve Boardwell
Jan 24, 2013, 12:57:22 PM1/24/13
to nexus-yu...@googlegroups.com
Hi,
I am using the Nexus 2.3.0-04 and have just set up the yum aliases for our various stages.
It's all a bit confusing but here are the infos and problems I gather are happening:
I am using the Nexus 2.3.0-04 and have just set up the yum aliases for our various stages.
It's all a bit confusing but here are the infos and problems I gather are happening:
- I created the aliases by calling the curl command.
- Different to website: I need to send a user and password with the request for the authorisation.
- After a little analysis I found authorisation is required for "http://mynexus.priv/nexus/service/local/..." onwards
- With the user and password it worked and the alias for dev can be seen under "http://mynexus.priv/nexus/service/local/yum/alias/releases/dev/".
- At the first time of setting, the repodata files (http://mynexus.priv/nexus/service/local/yum/repos/releases/dev/repodata/ ) are set-up correctly and everything is fine.
- When I set it again, the primary.xml.gz is suddenly empty.
- At some point, after setting to a different version and back again, running the "Yum - Generate Metadata" task, it works, but I don't know how
- In the yum.conf you can set aliasMappings. Are these needed when using the curl method.
- What happens when they are different?
- When is the alias repodata created exactly? Asynchronously, or at the time of the curl request, or some other time (deletion, addition of RPM in Nexus)?
- Could you perhaps give me a set of steps to follow in which I could:
- Set an alias for a stage
- Change that alias
- See the differences.
Thanks a lot. The plugin is great by the way. Hats off to you for the idea.
Steve
Steve Boardwell
Jan 24, 2013, 6:01:56 PM1/24/13
to nexus-yu...@googlegroups.com
So, I think I have solved it myself, but as I have just finished writing the problems down, here were my experiences until just now. I will write another reply with (what I hope to be at least) the solution.
Here is what I've experienced so far.
The command I use to set the alias:
[steve@server1 ~]$ curl --user user:password -d "0.7.0-2668" --header "Content-Type: text/plain" http://mynexus.priv/nexus/service/local/yum/alias/releases/it/
0.7.0-2668
The command I use to check the alias is set:
[steve@server1 ~]$ curl --user user:password http://mynexus.priv/nexus/service/local/yum/alias/releases/it/
0.7.0-2668
Looking at the alias repo I get a link to the underlying repodata:
[steve@server1 ~]$ curl --user user:password http://mynexus.priv/nexus/service/local/yum/repos/releases/it/
<html><head><title>File list</title></head><body><ul><li><a href="repodata/">repodata/</a></li></ul></html>
This repodata is however the versionized repo for the old it alias "0.7.0-2660" as opposed to "0.7.0-2668"
The (old aliased) repodata can be found under:
http://mynexus.priv/nexus/service/local/yum/repos/releases/0.7.0-2660/
The (newly aliased) repodata cannot be found. See below:
[steve@server1 ~]$ curl --user user:password http://mynexus.priv/nexus/service/local/yum/repos/releases/0.7.0-2668/
<html>
<head>
<title>404 - Not Found</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<link rel="icon" type="image/png" href="http://mynexus.priv/nexus/favicon.png"><!-- Major Browsers -->
<!--[if IE]><link rel="SHORTCUT ICON" href="http://mynexus.priv/nexus/favicon.ico"/><![endif]--><!-- Internet Explorer-->
<link rel="stylesheet" href="http://mynexus.priv/nexus/style/Sonatype-content.css?2.3.0-04" type="text/css" media="screen" title="no title" charset="utf-8">
</head>
<body>
<h1>404 - Not Found</h1>
<p>Couldn't find version or alias '0.7.0-2668' in repository 'releases'</p>
</body>
</html>
As mentioned, the alias is set correctly and the version can be found in the global (releases) primary.xml.gz
[steve@server1 ~]$ curl --user user:password http://mynexus.priv/nexus/service/local/yum/alias/releases/it/
0.7.0-2668
[steve@server1 ~]$ zgrep "0.7.0-2668" /usr/local/sonatype-work/nexus/storage/releases/repodata/primary.xml.gz
<location xml:base="http://mynexus.priv/nexus/content/repositories/releases" href="my/maven/group/rpmA-rpm/0.7.0-2668/rpmA-rpm-0.7.0-2668.rpm"/>
<rpm:sourcerpm>rpmA-rpm-0.7.0-2668.src.rpm</rpm:sourcerpm>
<location xml:base="http://mynexus.priv/nexus/content/repositories/releases" href="my/maven/group/rpmB-rpm/0.7.0-2668/rpmB-rpm-0.7.0-2668.rpm"/>
<rpm:sourcerpm>rpmB-rpm-0.7.0-2668.src.rpm</rpm:sourcerpm>
Here is what I've experienced so far.
The command I use to set the alias:
[steve@server1 ~]$ curl --user user:password -d "0.7.0-2668" --header "Content-Type: text/plain" http://mynexus.priv/nexus/service/local/yum/alias/releases/it/
0.7.0-2668
The command I use to check the alias is set:
[steve@server1 ~]$ curl --user user:password http://mynexus.priv/nexus/service/local/yum/alias/releases/it/
0.7.0-2668
Looking at the alias repo I get a link to the underlying repodata:
[steve@server1 ~]$ curl --user user:password http://mynexus.priv/nexus/service/local/yum/repos/releases/it/
<html><head><title>File list</title></head><body><ul><li><a href="repodata/">repodata/</a></li></ul></html>
This repodata is however the versionized repo for the old it alias "0.7.0-2660" as opposed to "0.7.0-2668"
The (old aliased) repodata can be found under:
http://mynexus.priv/nexus/service/local/yum/repos/releases/0.7.0-2660/
The (newly aliased) repodata cannot be found. See below:
[steve@server1 ~]$ curl --user user:password http://mynexus.priv/nexus/service/local/yum/repos/releases/0.7.0-2668/
<html>
<head>
<title>404 - Not Found</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<link rel="icon" type="image/png" href="http://mynexus.priv/nexus/favicon.png"><!-- Major Browsers -->
<!--[if IE]><link rel="SHORTCUT ICON" href="http://mynexus.priv/nexus/favicon.ico"/><![endif]--><!-- Internet Explorer-->
<link rel="stylesheet" href="http://mynexus.priv/nexus/style/Sonatype-content.css?2.3.0-04" type="text/css" media="screen" title="no title" charset="utf-8">
</head>
<body>
<h1>404 - Not Found</h1>
<p>Couldn't find version or alias '0.7.0-2668' in repository 'releases'</p>
</body>
</html>
As mentioned, the alias is set correctly and the version can be found in the global (releases) primary.xml.gz
[steve@server1 ~]$ curl --user user:password http://mynexus.priv/nexus/service/local/yum/alias/releases/it/
0.7.0-2668
[steve@server1 ~]$ zgrep "0.7.0-2668" /usr/local/sonatype-work/nexus/storage/releases/repodata/primary.xml.gz
<location xml:base="http://mynexus.priv/nexus/content/repositories/releases" href="my/maven/group/rpmA-rpm/0.7.0-2668/rpmA-rpm-0.7.0-2668.rpm"/>
<rpm:sourcerpm>rpmA-rpm-0.7.0-2668.src.rpm</rpm:sourcerpm>
<location xml:base="http://mynexus.priv/nexus/content/repositories/releases" href="my/maven/group/rpmB-rpm/0.7.0-2668/rpmB-rpm-0.7.0-2668.rpm"/>
<rpm:sourcerpm>rpmB-rpm-0.7.0-2668.src.rpm</rpm:sourcerpm>
Herold, Sebastian
Jan 24, 2013, 6:10:32 PM1/24/13
to <nexus-yum-plugin@googlegroups.com>
Hi Steve,
I admit it's a lit bit confusing, but the version for aliases do not reflect the version in the RPM header. What counts is the maven version, that means the name of the parent directory the RPM is in. Could you please send me the last parts of the RPM paths as mentioned in primary.xml.gz -> location -> href? Maybe this could clarify your problem.
Regards,
Sebastian
I admit it's a lit bit confusing, but the version for aliases do not reflect the version in the RPM header. What counts is the maven version, that means the name of the parent directory the RPM is in. Could you please send me the last parts of the RPM paths as mentioned in primary.xml.gz -> location -> href? Maybe this could clarify your problem.
Regards,
Sebastian
Steve Boardwell
Jan 24, 2013, 6:27:10 PM1/24/13
to nexus-yu...@googlegroups.com
So, the solution or at least an explanation of the problem.
@Sebastian: I've just received your post per mail. Yes, I gathered that the version would be the maven version, that isn't the problem I think.
The Problem:
I think I may have tried to change to the new alias too quickly, that is before the new global (to the main nexus repository) repodata primary.xml.gz was updated.
For the aliases to work, RPMs must be in Nexus and have been processed by the Yum Generate Metadata Task, and therefore also in the global repodata.
If this is not the case, i.e.
Steps (I think) to reproduce:
I am guessing that the versionized repos are cached somewhere and once built, cannot be rebuilt. That was, I think, my problem.
Cheers,
Steve
@Sebastian: I've just received your post per mail. Yes, I gathered that the version would be the maven version, that isn't the problem I think.
The Problem:
I think I may have tried to change to the new alias too quickly, that is before the new global (to the main nexus repository) repodata primary.xml.gz was updated.
For the aliases to work, RPMs must be in Nexus and have been processed by the Yum Generate Metadata Task, and therefore also in the global repodata.
If this is not the case, i.e.
- the RPMs Artifacts are in Nexus
- but not yet processed and in the global repodata,
Steps (I think) to reproduce:
- Set up an alias with an existing Artifact
- Deploy a new artifact to Nexus
- Immediately, after deployment (before the Yum Generate Metadata Task has a chance to work) set the new alias and try to access the aliased yum-repo.
I am guessing that the versionized repos are cached somewhere and once built, cannot be rebuilt. That was, I think, my problem.
In the end, I solved the problem by:
- commenting out the mappedAliases in the yum.conf (I am guessing they are there to pre-load on startup or something similar)
- restarting the server.
- running Yum Generate Metadata to ensure all RPM artifacts were processed before testing the aliases
Now it seems everything it working correctly. A couple of questions that arose:
- Is it possible to remove an alias? I tried -X DELETE with curl but it didn't do anything.
- Is it possible to rebuild a versioned yum-repo in the way that the YUM Generate Metadata does it for the global repodata?
@Sebastian: Thanks for the quick reply by the way.
Cheers,
Steve
Steve Boardwell
Jan 25, 2013, 6:04:45 PM1/25/13
to nexus-yu...@googlegroups.com
We had a few more problems today. The automatic yum generate metadata task was not being executed when deploying to Nexus.
I deleted the Task I had created yesterday and that has solved the problem. The task was the Yum Generate Metadata on the releases repository. I hadn't set it to run on a schedule because I wanted to be able to run it manually.
Is it possible that the task scheduled for manual execution was somehow interfering/overriding the automatic/triggered execution of the Generate Metadata task? It's just a thought but it would also fit time-wise with the problems I was having yesterday.
Cheers again,
Steve
Herold, Sebastian
Jan 26, 2013, 3:44:39 AM1/26/13
to <nexus-yum-plugin@googlegroups.com>
Thanks for your ongoing investigation. You are right, if there is already a scheduled task for the same repository in the scheduler queue, a new one will not be added.
Regards,
Sebastian
Regards,
Sebastian
Steve Boardwell
Jan 26, 2013, 3:59:26 AM1/26/13
to nexus-yu...@googlegroups.com
Ok, thanks. That explains a lot. It might be worth adding this to the documentation as a potential pit-fall to help others in the future. Or would it be possible to allow 'manual' (not scheduled by nature, or scheduled never to run automatically) tasks. My 'manually' added task was not running or scheduled to run and should therefore not have been in any queue. Or by queue, do you mean the list of scheduled tasks in the Nexus Web-UI?
Thanks,
Steve
Reply all
Reply to author
Forward
0 new messages