mini-dinstall, repository signing and apt-get authentication
Neil Williams
sponsor can obtain my packages more easily.
I've generated a gpg key to sign the Release files and I'm using
mini-dinstall on the server. It appears to be working, Release and
Release.gpg are created and gpg can verify that the signature is good.
$ gpg --verify Release.gpg Release
gpg: Signature made Tue Jul 25 14:04:53 2006 BST using DSA key ID 6C7D3C63
gpg: Good signature from "Data Freedom Repository Signing Key
(www.data-freedom.org/packages/) <li...@codehelp.co.uk>"
I've added that key to apt using sudo apt-key add and it's listed OK.
Yet apt-get update doesn't seem to locate Release.gpg correctly:
Ign http://www.linux.codehelp.co.uk packages/unstable/all/ Release.gpg
and trying to install a package from the repository still gives
authentication errors.
$ sudo apt-get install pilot-qof
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed
pilot-qof
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 94.4kB of archives.
After unpacking 516kB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
pilot-qof
Install these packages without verification [y/N]?
E: Some packages could not be authenticated
Repository:
deb http://www.linux.codehelp.co.uk/ packages/unstable/$(ARCH)/
deb http://www.linux.codehelp.co.uk/ packages/unstable/all/
deb-src http://www.linux.codehelp.co.uk/ packages/unstable/source/
Signing key:
http://www.linux.codehelp.co.uk/packages/0x6c7d3c63.txt
(not on keyservers yet in case this doesn't work out.)
mini-dinstall conf:
[DEFAULT]
archivedir=<private path removed from message to list>
mailto=li...@codehelp.co.uk
architectures=all, i386, amd64, powerpc
archive_style=simple-subdir
generate_release=1
release_codename="data-freedom"
release_description="Data Freedom demo packages"
release_label="Data Freedom demo packages"
release_origin="Neil Williams <li...@codehelp.co.uk>"
release_signscript=<private path removed from message to list>
extra_keyrings=<private path removed from message to list>
I'm not getting mail from mini-dinstall either.
Any idea what I've done wrong?
I've read that Release needs to be present in the subdirectories but
mini-dinstall normally looks after everything in those subdirectories.
It deletes "Release" files that I create in the top level directory.
The generated Release file looks OK:
Origin: "Neil Williams <li...@codehelp.co.uk>"
Label: "Data Freedom demo packages"
Suite: unstable
Codename: "data-freedom"
Date: Tue, 25 Jul 2006 13:04:51 UTC
Architectures: all i386 amd64 powerpc
Description: "Data Freedom demo packages"
MD5Sum:
3de6c35bd94e74a41459b728a2d925f4 900 all/Packages
....
etc.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Jeremy Stanley
[...]
> I've generated a gpg key to sign the Release files and I'm using
> mini-dinstall on the server. It appears to be working, Release and
> Release.gpg are created and gpg can verify that the signature is good.
> Yet apt-get update doesn't seem to locate Release.gpg correctly:
>
> Ign http://www.linux.codehelp.co.uk packages/unstable/all/ Release.gpg
Looks like it's trying to retrieve:
http://www.linux.codehelp.co.uk/packages/unstable/all/Release.gpg
...when you instead provide:
http://www.linux.codehelp.co.uk/packages/unstable/Release.gpg
I just use a dirty shell script with apt-ftparchive to generate a
little mini-repository of my projects like so:
#!/bin/sh
cd debian
rm -f Contents.bz2 Contents.gz Packages.bz2 Packages.gz Release \
Release.gpg Sources.bz2 Sources.gz
apt-ftparchive contents . > Contents
bzip2 -k Contents
gzip -9 Contents
apt-ftparchive packages . > Packages
bzip2 -k Packages
gzip -9c Packages > Packages.gz
apt-ftparchive sources . > Sources
bzip2 -k Sources
gzip -9c Sources > Sources.gz
apt-ftparchive release . > Release
rm Packages Sources
gpg --armor --default-key ="Jeremy Stanley <fu...@yuggoth.org>" \
--detach-sign --output Release.gpg Release
This has been working fine for me with apt-get/apt-key so far.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Neil Williams
> On Tue, Jul 25, 2006 at 02:33:04PM +0100, Neil Williams wrote:
> [...]
>> I've generated a gpg key to sign the Release files and I'm using
>> mini-dinstall on the server. It appears to be working, Release and
>> Release.gpg are created and gpg can verify that the signature is good.
> [...]
>> Yet apt-get update doesn't seem to locate Release.gpg correctly:
>>
>> Ign http://www.linux.codehelp.co.uk packages/unstable/all/ Release.gpg
> [...]
>
> Looks like it's trying to retrieve:
>
> http://www.linux.codehelp.co.uk/packages/unstable/all/Release.gpg
>
> ...when you instead provide:
>
> http://www.linux.codehelp.co.uk/packages/unstable/Release.gpg
Yes, I realise that. The problem is why it's not being generated when
Packages and Sources *are* being generated. It's not as simple as moving
a file around.
> I just use a dirty shell script with apt-ftparchive
I used to use that but it's hard to get it to auto-update with uploads
by dput. That's where mini-dinstall comes in.
>to generate a
> little mini-repository of my projects like so:
>
> #!/bin/sh
> cd debian
> apt-ftparchive release . > Release
> gpg --armor --default-key ="Jeremy Stanley <fu...@yuggoth.org>" \
> --detach-sign --output Release.gpg Release
>
> This has been working fine for me with apt-get/apt-key so far.
That's what I used to use but this method can't be used with
mini-dinstall. It looks like your repository is a single subdirectory
whereas mine uses multiple subdirectories for the multiple
architectures. Each one, apparently, needs a customised Release file.
My question is why mini-dinstall doesn't seem to be configured properly
to do this part of the update.
George Danchev
--cut--
> That's what I used to use but this method can't be used with
> mini-dinstall. It looks like your repository is a single subdirectory
> whereas mine uses multiple subdirectories for the multiple
> architectures. Each one, apparently, needs a customised Release file.
let mini-dinstall generates these Release files on the server side, then
download them, sign them locally locally and put them back again. Something
like that:
scp $HOST:$DIR/$dist/Release $TMP/
gpg --armour --yes -o $TMP/Release.gpg -b $TMP/Release
scp $TMP/Release.gpg $HOST:$DIR/$dist/
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Neil Williams
> On Tuesday 25 July 2006 21:20, Neil Williams wrote:
> --cut--
>> That's what I used to use but this method can't be used with
>> mini-dinstall. It looks like your repository is a single subdirectory
>> whereas mine uses multiple subdirectories for the multiple
>> architectures. Each one, apparently, needs a customised Release file.
>
> let mini-dinstall generates these Release files on the server side
This is a problem. mini-dinstall does not create all the required
Release files. It only creates the top level Release file.
When I try to create a Release file with apt-ftparchive in the
architecture-specific subdirectory, apt-ftparchive recurses UP the tree
and interferes with the Release file generated by mini-dinstall in the
directory above. The Release file written by apt-ftparchive is not valid
anyway.
W: Conflicting distribution: http://www.linux.codehelp.co.uk
packages/unstable/amd64/ Release (expected packages/unstable/amd64 but
got "data-freedom")
I've had to delete the Release and Release.gpg files from each
subdirectory for now.
When I create a dummy Release file, apt-get update complains that no
MD5Sum entries are found so I need to copy the Release file from the
directory above. Doing that then confuses apt-get without some nasty sed
hacking to mangle the directory names for each MD5Sum to correctly
identify the subdirectory and limit the Architecture: line to just the
architecture in that subdirectory.
It appears that mini-dinstall simply does not support all the declared
options. generate-release does not appear to work for
archive_style=simple-subdir, at least it doesn't if more than one
architecture is specified.
Time for a bug report, I think. But in order to actually get the thing
working, I need more help.
Is there another way of generating a Release file?
What is the underlying method, avoiding all use of devscript tools?
I'm now trying a brute force method:
$ cp /home/neil/Release.amd64 ./Release
$ md5sum Packages >> Release
$ md5sum Packages.gz >> Release
$ echo "SHA1:" >> ./Release
$ sha1sum Packages >> ./Release
$ sha1sum Packages.gz >> ./Release
then signing the Release file to create Release.gpg
I get:
Failed to fetch
http://www.linux.codehelp.co.uk/packages/unstable/amd64/Release Unable
to find expected entry Packages in Meta-index file (malformed Release
file?)
The base Release file is:
Archive: unstable
Origin: "Neil Williams <li...@codehelp.co.uk>"
Component: main
Label: "Data Freedom demo packages"
Architecture: amd64
Packages: amd64/Packages
MD5Sum:
What's missing / wrong?
(I've tried with and without the Packages: line. The rest is as per the
Debian Repository HOWTO.)
For this repository:
http://www.linux.codehelp.co.uk/packages/unstable/amd64/Release
What should the Release file in amd64/ contain?
Darren Salt
[snip]
> I'm now trying a brute force method:
> $ cp /home/neil/Release.amd64 ./Release
> $ md5sum Packages >> Release
> $ md5sum Packages.gz >> Release
> $ echo "SHA1:" >> ./Release
> $ sha1sum Packages >> ./Release
> $ sha1sum Packages.gz >> ./Release
> then signing the Release file to create Release.gpg
What I use for my repository is attached. (Licence is GPL >= v2.)
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| Say NO to UK ID cards. http://www.no2id.net/
I will never lie to me.
Neil Williams
> What I use for my repository is attached. (Licence is GPL >= v2.)
Excellent! Thank you!
I've tweaked it a little so far to accept the architecture name as the
first command option and I'm running it manually after changing into
each directory. It should be simple to automate from there, including
tacking on the command to sign the Release file.
With mini-dinstall now set to *not* create Release files, I just need to
create a suitable wrapper to run as a post-install script via
mini-dinstall itself.
$ cd amd64/
$ rm Release
$ bash ~/release.sh amd64
$ ~/.scripts/.sign Release
$ cd ../powerpc/
etc.
At the top level, (when $1 is not set), it simply outputs a replacement
string that includes each arch.
if [ ! $1 ]
then
ARCH="all amd64 powerpc i386"
codename="packages/$i"
else
ARCH=$1
codename="packages/$i/$ARCH"
fi
It works!
Ian Zimmerman
Neil> Time for a bug report, I think. But in order to actually get the
Neil> thing working, I need more help.
Have you ever filed the report? I can't find it searching on b.d.o.
Neil> I get:
Neil> Failed to fetch
Neil> http://www.linux.codehelp.co.uk/packages/unstable/amd64/Release
Neil> Unable to find expected entry Packages in Meta-index file (malformed Release file?)
And this is my main question: have you figured out what causes this error?
I am pretty much in banging-head-against-wall mode now.
Let me describe my situation: I have a flat (single directory) archive
of personal debs. I see absolutely no point in maintaining "code names"
and "suites" and what not. So I put the debs into /var/local/debian
(which apache aliases to /debian/) on my.server.com, and in the clients'
sources.list I put
deb http://my.server.com/debian/ ./
I generate the Packages.gz file by
cd /var/local/debian && apt-ftparchive packages ./ | gzip - > Packages.gz
and the Release file by
cd /var/local/debian && apt-ftparchive release ./ > /tmp/Release && mv /tmp/Release .
Followed by apt-get update on the clients of course.
All this works flawlessly until I introduce signing. As soon as I add a Release.gpg
file (generated by cd /var/local/debian && gpg -abs -o Release.gpg Release)
apt-get starts giving me the above error message. Now the wording made me think
that perhaps perhaps I should NOT compress the Packages file, so I tried to omit
the gzip step above. But then apt-get complains it cannot retrieve Packages file!
<rant>
It seems the security layer of apt was a quick hack which introduced this sort
of confusion, instead of the thoughtful redesign it needed.
</rant>
Thanks for your help in advance.
--
This line is completely ham.
Neil Williams
Ian Zimmerman <i...@madbat.mine.nu> wrote:
> Neil> Time for a bug report, I think. But in order to actually get the
> Neil> thing working, I need more help.
I wish you'd included the fact that the original email is from:
Date: 2006-07-28 21:09 +100
It's very confusing getting a reply from an email that old!
http://lists.debian.org/debian-mentors/2006/07/msg00345.html
> Have you ever filed the report? I can't find it searching on b.d.o.
Didn't need to - I switched to reprepro instead.
mini-dinstall isn't really designed for my kind of repository and I
didn't see any point filing a bug report to make mini-dinstall more
like reprepro when reprepro was (and is) simply a better choice for
anything more than a very simple repository.
> And this is my main question: have you figured out what causes this error?
Yes - the error is caused by not using reprepro.
:-)
> Let me describe my situation: I have a flat (single directory) archive
> of personal debs. I see absolutely no point in maintaining "code names"
> and "suites" and what not.
reprepro doesn't force these on you but it does not stop you adding
them later either.
> I generate the Packages.gz file by
>
> cd /var/local/debian && apt-ftparchive packages ./ | gzip - > Packages.gz
Yuk. There should be no need to do this.
> and the Release file by
>
> cd /var/local/debian && apt-ftparchive release ./ > /tmp/Release && mv /tmp/Release .
Nor that.
> All this works flawlessly until I introduce signing. As soon as I add a Release.gpg
> file (generated by cd /var/local/debian && gpg -abs -o Release.gpg Release)
> apt-get starts giving me the above error message. Now the wording made me think
> that perhaps perhaps I should NOT compress the Packages file, so I tried to omit
> the gzip step above. But then apt-get complains it cannot retrieve Packages file!
No. The error is because mini-dinstall doesn't support what you want.
> <rant>
> It seems the security layer of apt was a quick hack which introduced this sort
> of confusion, instead of the thoughtful redesign it needed.
> </rant>
No. IMHO mini-dinstall is the quick hack which isn't capable of
supporting advanced features like SecureApt.
Use the right tool for the job.
Ian Zimmerman
Ian> And this is my main question: have you figured out what causes this error?
Neil> Yes - the error is caused by not using reprepro.
Neil> :-)
I am afraid from my POV this is not particularly funny. The
documentation (i.e. the apt manual and the secure apt wiki) doesn't
mention reprepro (or mini-dinstall), I was trying to do this the
documented way (well, except having a flat directory), and it didn't
work. I don't feel "just use whiz-bang tool foo" is the correct answer
in such a situation, or at least it is not the complete answer. That
would include at least acknowledging that the documentation is wrong.
Ian> Let me describe my situation: I have a flat (single directory) archive
Ian> of personal debs. I see absolutely no point in maintaining "code names"
Ian> and "suites" and what not.
Neil> reprepro doesn't force these on you but it does not stop you adding
Neil> them later either.
OK, I'll take a look at reprepro.
Ian> I generate the Packages.gz file by
Ian>
Ian> cd /var/local/debian && apt-ftparchive packages ./ | gzip - >
Ian> Packages.gz
Neil> Yuk. There should be no need to do this.
Ian> and the Release file by
Ian>
Ian> cd /var/local/debian && apt-ftparchive release ./ > /tmp/Release &&
Ian> mv /tmp/Release .
Neil> Nor that.
This is all straight from the wiki.
Ian> All this works flawlessly until I introduce signing. As soon as I
Ian> add a Release.gpg file (generated by cd /var/local/debian && gpg
Ian> -abs -o Release.gpg Release) apt-get starts giving me the above
Ian> error message. Now the wording made me think that perhaps perhaps
Ian> I should NOT compress the Packages file, so I tried to omit the
Ian> gzip step above. But then apt-get complains it cannot retrieve
Ian> Packages file!
Neil> No. The error is because mini-dinstall doesn't support what you want.
Huh? I didn't use mini-dinstall at all. I was generating the metadata
manually, in the documented format.
Neil> No. IMHO mini-dinstall is the quick hack which isn't capable of
Neil> supporting advanced features like SecureApt.
Again, I didn't use mini-dinstall - I generated the Secure Apt files
as documented.
Neil Williams
Ian Zimmerman <i...@madbat.mine.nu> wrote:
> Ian> And this is my main question: have you figured out what causes
> Ian> this error?
>
> Neil> Yes - the error is caused by not using reprepro.
> Neil> :-)
>
> I am afraid from my POV this is not particularly funny. The
> documentation (i.e. the apt manual and the secure apt wiki) doesn't
> mention reprepro (or mini-dinstall), I was trying to do this the
> documented way (well, except having a flat directory)
I have no idea about the docs, I just use the tool(s) that work.
I was using mini-dinstall, you appear not to be. Any solution I used
would not be applicable to your usage.
>, and it didn't
> work. I don't feel "just use whiz-bang tool foo" is the correct
> answer in such a situation, or at least it is not the complete
> answer. That would include at least acknowledging that the
> documentation is wrong.
I've no idea if the documentation that you mention is right or wrong. I
was using mini-dinstall - you are not. I'm not sure why you think my
experience is applicable to a different method.
> Ian> All this works flawlessly until I introduce signing. As soon as
> Ian> I add a Release.gpg file (generated by cd /var/local/debian &&
> Ian> gpg -abs -o Release.gpg Release) apt-get starts giving me the
> Ian> above error message. Now the wording made me think that perhaps
> Ian> perhaps I should NOT compress the Packages file, so I tried to
> Ian> omit the gzip step above. But then apt-get complains it cannot
> Ian> retrieve Packages file!
>
> Neil> No. The error is because mini-dinstall doesn't support what you
> Neil> want.
>
> Huh? I didn't use mini-dinstall at all. I was generating the
> metadata manually, in the documented format.
Then maybe it would have been an idea to change the subject line of
this year-old reply??!!
I have no idea how to continue this thread - I didn't use the method
you describe, the bug report that I was considering (a YEAR ago!) is
completely inapplicable to your method because the bug was meant to be
against mini-dinstall, not the docs. I am now using reprepro
exclusively and I don't think I can help you - other than advise you,
as I did, to switch to reprepro. I know it works. I'm not responsible
for the docs and I'm not a repository expert or maintainer of
repository-related packages but if some of the docs are on the wiki,
feel free to correct them.
Ian Zimmerman
Neil> reprepro doesn't force these on you but it does not stop you
Ian> OK, I'll take a look at reprepro.
I did. reprepro still wants me to have a pool and dists subdirectories,
at the very least. This just makes it more complicated to maintain,
in particular to upload the debs.
I don't think reprepro is the right tool for my job, either. Again,
this is _not_ a mirror. It is just a bunch of debs (about 30 right now)
that I build myself on a desktop machine, then upload to share with other
client machines.
Is _anyone_ else doing this? Seems like a natural thing to do.
Julien Valroff
> Neil> reprepro doesn't force these on you but it does not stop you
> Neil> adding them later either.
>
> Ian> OK, I'll take a look at reprepro.
>
> I did. reprepro still wants me to have a pool and dists subdirectories,
> at the very least. This just makes it more complicated to maintain,
> in particular to upload the debs.
>
> I don't think reprepro is the right tool for my job, either. Again,
> this is _not_ a mirror. It is just a bunch of debs (about 30 right now)
> that I build myself on a desktop machine, then upload to share with other
> client machines.
>
> Is _anyone_ else doing this? Seems like a natural thing to do.
And I think I have less than 30 packages in my repository!
This tool is both easy and powerful, just as I like. Read carfeully the
documentation and you will understand reprepro is not just a mirror
tool, and uploads made by tools like dupload or dput are processed very
easily directly by reprepro.
Cheers,
Julien
Cameron Dale
> I did. reprepro still wants me to have a pool and dists subdirectories,
> at the very least. This just makes it more complicated to maintain,
> in particular to upload the debs.
>
> I don't think reprepro is the right tool for my job, either. Again,
> this is _not_ a mirror. It is just a bunch of debs (about 30 right now)
> that I build myself on a desktop machine, then upload to share with other
> client machines.
>
> Is _anyone_ else doing this? Seems like a natural thing to do.
I use reprepro for exactly this purpose, and I only have about 10 debs
in it at any given time. reprepro just makes it easier to handle all
the Packages.gz/Release creation and signing. Adding new files is as
sinple as "reprepro include sid ..." and removing them "reprepro
remove sid ...", everything else is handled for you.
How is uploading complicated? I added a post-upload script to dupload
so I can just do (on any machine) "dupload --to sid foo.changes &&
apt-get update" and it all just works, I don't even have to log in to
the reprepro machine.
Cameron
Neil Williams
Ian Zimmerman <i...@madbat.mine.nu> wrote:
>
> Neil> reprepro doesn't force these on you but it does not stop you
> Neil> adding them later either.
>
> Ian> OK, I'll take a look at reprepro.
>
> I did. reprepro still wants me to have a pool and dists subdirectories,
I don't see the harm. It is the expected structure of a repository and
makes it easy for other tools to work with it. If you want a repository
that is easy to maintain, use a tool that creates a layout that most
tools will understand.
It sounds like you want a simple-complex repository - 'simple' bits
able to support the complex requirements of SecureApt. What is so wrong
with a slightly increased directory tree if it gives you the ease of
maintenance AND SecureApt?
Seems to me you have two choices: Use what you had without SecureApt.
Use the directory layout and tools that support SecureApt.
IMHO the first is short-sighted and unmaintainable because further
changes in repository handling will only increase your difficulty
in maintaining a bespoke layout.
> at the very least. This just makes it more complicated to maintain,
> in particular to upload the debs.
dput ?
> I don't think reprepro is the right tool for my job, either. Again,
> this is _not_ a mirror.
Neither are my reprepro repositories. One handles less than a dozen packages.
If you want apt authentication to work with your layout, you have to
ensure that it abides by how apt expects to use the layout - the
easiest way to do that is with a tool that is known to work with apt
authentication, like reprepro.
Ian Zimmerman
> Unable to find expected entry Packages in Meta-index file (malformed Release file?)
Ian> And this is my main question: have you figured out what causes this
Ian> error?
Neil> I've no idea if the documentation that you mention is right or
Neil> wrong. I was using mini-dinstall - you are not. I'm not sure why
Neil> you think my experience is applicable to a different method.
[...]
Neil> Then maybe it would have been an idea to change the subject line
Neil> of this year-old reply??!!
Fair enough.
So, does anyone have an idea what's really causing that error?
Joey Hess
> Seems to me you have two choices: Use what you had without SecureApt.
> Use the directory layout and tools that support SecureApt.
There is nothing in apt's security checking code that requires any
particular repository structure.
Example of apt repository that uses a flat directory structure, created
by mini-dinstall, including fully automated creation of signed Release
files usable by apt: http://kitenet.net/~joey/debian/unstable/
--
see shy jo
Ian Zimmerman
Ian> I don't think reprepro is the right tool for my job, either.
Ian> Again, this is _not_ a mirror. It is just a bunch of debs (about
Ian> 30 right now) that I build myself on a desktop machine, then upload
Ian> to share with other client machines.
Ian>
Ian> Is _anyone_ else doing this? Seems like a natural thing to do.
Cameron> I use reprepro for exactly this purpose, and I only have about
Cameron> 10 debs in it at any given time. reprepro just makes it easier
Cameron> to handle all the Packages.gz/Release creation and
Cameron> signing. Adding new files is as sinple as "reprepro include sid
Cameron> ..." and removing them "reprepro remove sid ...", everything
Cameron> else is handled for you.
Cameron> How is uploading complicated? I added a post-upload script to
Cameron> dupload so I can just do (on any machine) "dupload --to sid
Cameron> foo.changes && apt-get update" and it all just works, I don't
Cameron> even have to log in to the reprepro machine.
dupload?? Cheesus. I don't even know what that is.
I see that I have to describe exactly what I do from the point of build.
In the source directory of a package, I do
fakeroot debian/rules binary
that will create a file ../foo.deb,
then
scp ../foo.deb my.server.com:/var/local/debian
then I ssh to my.server.com and do the steps I described in my first mail
(as given by the wiki).
Why does it have to be any more complicated than this? It worked pre-signing.
If it can't work with signing anymore, why? And shouldn't this be documented?
--
This line is completely ham.
Neil Williams
Ian Zimmerman <i...@madbat.mine.nu> wrote:
> I see that I have to describe exactly what I do from the point of build.
> In the source directory of a package, I do
>
> fakeroot debian/rules binary
>
> that will create a file ../foo.deb,
> then
dput foo_version_arch.changes
then let the server do the rest. No need to login.
It works well - principally because it is how packages are uploaded to
Debian so it needs to work!
(dput supports ftp or ssh).
> scp ../foo.deb my.server.com:/var/local/debian
>
> then I ssh to my.server.com and do the steps I described in my first mail
dput combines all that into one command.
> (as given by the wiki).
>
> Why does it have to be any more complicated than this?
It's actually less complicated.
However, see Joey's email about his repository that sounds a lot closer
to what you originally wanted.
Cameron Dale
> Cameron> How is uploading complicated? I added a post-upload script to
> Cameron> dupload so I can just do (on any machine) "dupload --to sid
> Cameron> foo.changes && apt-get update" and it all just works, I don't
> Cameron> even have to log in to the reprepro machine.
>
> dupload?? Cheesus. I don't even know what that is.
Are you completely against using tools to make your life easier?
You're saying you want it to be less complicated, but you're already
over-complicating it by not using tools others have built for exactly
this situation. dupload just automates the scp to a server and allows
you to do more with it.
> I see that I have to describe exactly what I do from the point of build.
> In the source directory of a package, I do
>
> fakeroot debian/rules binary
dpkg-buildpackage might be better.
> that will create a file ../foo.deb,
> then
>
> scp ../foo.deb my.server.com:/var/local/debian
Here's where dupload would come in handy
> then I ssh to my.server.com and do the steps I described in my first mail
> (as given by the wiki).
Again, this is unnecessary, and could all be handled by reprepro (as I
said, I don't even have to log in to the server, it's all done by
dupload).
> Why does it have to be any more complicated than this? It worked pre-signing.
> If it can't work with signing anymore, why? And shouldn't this be documented?
So stick with non-SecureApt for your simple situation, or use the
advanced tools to get an advanced situation (which is IMO less
complicated).
If you're completely against using the tools, but must have SecureApt,
why not post a link to your repository and we can help diagnose the
problem you're having. I'd be willing to take a look at it to see
where the errors are coming from (I'm no apt expert, but I've had to
diagnose similar problems in the past).
Cameron
Ian Zimmerman
Cameron> Are you completely against using tools to make your life
Cameron> easier? You're saying you want it to be less complicated, but
Cameron> you're already over-complicating it by not using tools others
Cameron> have built for exactly this situation.
My beef is that the docs are in terms of the (pre-signing) primitives,
and nowhere does it say "You cannot do this anymore with the new
apt/with signing." If I was told like this by, e.g., the manpage of
dpkg-scanpackages or apt-ftparchive, I would have migrated at some
point.
Cameron> dupload just automates the scp to a server and allows you to do
Cameron> more with it.
Yeah, but more is not always better :-(
dupload requires me to make a .changes file. I'd rather not have these
overpopulating the source area.
Also, to have the one-step process you describe, I either have to be root
or give myself write permissions to the archive. Currently I do the build
as myself but the remote part as root.
Cameron> So stick with non-SecureApt for your simple situation, or use
Cameron> the advanced tools to get an advanced situation (which is IMO
Cameron> less complicated).
I would, except that every time I make an update aptitude gives me a
red fat warning "Untrusted version of packages will be installed."
I don't see a way of turning that off.
Cameron> If you're completely against using the tools, but must have
Cameron> SecureApt, why not post a link to your repository and we can
Cameron> help diagnose the problem you're having. I'd be willing to take
Cameron> a look at it to see where the errors are coming from (I'm no
Cameron> apt expert, but I've had to diagnose similar problems in the
Cameron> past).
Thank you sincerely for your offer. To do this safely I need to
actually open the http port for you, and mail you the link privately.
Can you privately email me a source IP range to open it for?
--
This line is completely ham.
Cameron Dale
> dupload requires me to make a .changes file. I'd rather not have these
> overpopulating the source area.
>
> Also, to have the one-step process you describe, I either have to be root
> or give myself write permissions to the archive. Currently I do the build
> as myself but the remote part as root.
Actually, you would just do the scp to a root account, though maybe
that's not what you want either. My archive is owned by me, and I
can't think of a reason why it should be root owned, do you have a
good one (it's beside the point, I'm just curious)?
> Cameron> So stick with non-SecureApt for your simple situation, or use
> Cameron> the advanced tools to get an advanced situation (which is IMO
> Cameron> less complicated).
>
> I would, except that every time I make an update aptitude gives me a
> red fat warning "Untrusted version of packages will be installed."
> I don't see a way of turning that off.
I think there's an Apt option for this, though I can't find it right now.
Cameron
Ian Zimmerman
Cameron> Actually, you would just do the scp to a root account, though
Cameron> maybe that's not what you want either. My archive is owned by
Cameron> me, and I can't think of a reason why it should be root owned,
Cameron> do you have a good one (it's beside the point, I'm just
Cameron> curious)?
Well, one cannot get root on that server except by ssh with my private
key, while my own account has a normal password (it has to because the
server also does mail with plain authentication, over SSL of course).
So I consider the normal account slightly more vulnerable.
Cameron> I think there's an Apt option for this, though I can't find it
Cameron> right now.
I thought there should be one :-) but couldn't find one either.
--
This line is completely ham.
Cameron Dale
> Let me describe my situation: I have a flat (single directory) archive
> of personal debs. I see absolutely no point in maintaining "code names"
> and "suites" and what not. So I put the debs into /var/local/debian
> (which apache aliases to /debian/) on my.server.com, and in the clients'
> sources.list I put
>
> deb http://my.server.com/debian/ ./
>
> I generate the Packages.gz file by
>
> cd /var/local/debian && apt-ftparchive packages ./ | gzip - > Packages.gz
After looking at your repository, I have determined that this is where
the problem occurs. You need to also generate a Packages file
(uncompressed). You still need the Packages.gz file though, as apt
only wants to download that one. So, changing the command to:
cd /var/local/debian && \
apt-ftparchive packages ./ > Packages && \
gzip -c Packages > Packages.gz
should work to create both files. (It's worth noting that you could
probably create an apt-ftparchive config file, and then creating both
Packages files and the Release file would only involve one invocation
of "apt-ftparchive generate".)
> and the Release file by
>
> cd /var/local/debian && apt-ftparchive release ./ > /tmp/Release && mv /tmp/Release .
>
> Followed by apt-get update on the clients of course.
>
> All this works flawlessly until I introduce signing. As soon as I add a Release.gpg
> file (generated by cd /var/local/debian && gpg -abs -o Release.gpg Release)
> apt-get starts giving me the above error message. Now the wording made me think
> that perhaps perhaps I should NOT compress the Packages file, so I tried to omit
> the gzip step above. But then apt-get complains it cannot retrieve Packages file!
It also works fine if you don't have the key in the apt secure key
ring. I'm not sure why this is, but adding a successful key check
seems to create this problem. There's almost certainly a bug in apt
somewhere here, or maybe a couple, since I don't think apt should
require a Packages file when it has no intention of downloading it.
Cameron
Daniel Leidert
[..]
> Neil> I get:
> Neil> Failed to fetch
> Neil> http://www.linux.codehelp.co.uk/packages/unstable/amd64/Release
> Neil> Unable to find expected entry Packages in Meta-index file (malformed Release file?)
>
> And this is my main question: have you figured out what causes this error?
> I am pretty much in banging-head-against-wall mode now.
[..]
> and the Release file by
>
> cd /var/local/debian && apt-ftparchive release ./ > /tmp/Release && mv /tmp/Release .
Hm. The release files will not contain much information except the Date
and the hash-sums. Am I wrong?
> Followed by apt-get update on the clients of course.
>
> All this works flawlessly until I introduce signing. As soon as I add a Release.gpg
> file (generated by cd /var/local/debian && gpg -abs -o Release.gpg Release)
> apt-get starts giving me the above error message. Now the wording made me think
> that perhaps perhaps I should NOT compress the Packages file, so I tried to omit
> the gzip step above. But then apt-get complains it cannot retrieve Packages file!
IIRC there was some requirement. IIRC you need Packages, Packages.gz
(and maybe Packages.bz2) at creation time of the Release file and only
after creating this file, you can remove those you don't need/want to
offer (e.g. Packages and Packages.bz2). IIRC there is some limitation of
this kind - however, I'm not sure about the correct wording. Maybe
that's the reason, why you get the error.
> <rant>
> It seems the security layer of apt was a quick hack which introduced this sort
> of confusion, instead of the thoughtful redesign it needed.
> </rant>
You have many choices besides mini-dinstall:
http://wiki.debian.org/HowToSetupADebianRepository, which work well for
secure-apt. I guess, most of them are better suited for your purpose
than mini-dinstall is. I personally use debarchiver on my server via scp
(dput). And I only need to login, if I want to remove something from the
repository. I also heard about reprepro being used on remote servers.
Regards, Daniel
Ian Zimmerman
>> cd /var/local/debian && apt-ftparchive packages ./ | gzip - >
>> Packages.gz
Cameron> After looking at your repository, I have determined that this
Cameron> is where the problem occurs. You need to also generate a
Cameron> Packages file (uncompressed). You still need the Packages.gz
Cameron> file though, as apt only wants to download that one. So,
Cameron> changing the command to:
Cameron> cd /var/local/debian && \ apt-ftparchive packages ./ > Packages
Cameron> && \ gzip -c Packages > Packages.gz
Cameron> should work to create both files. (It's worth noting that you
Cameron> could probably create an apt-ftparchive config file, and then
Cameron> creating both Packages files and the Release file would only
Cameron> involve one invocation of "apt-ftparchive generate".)
This was indeed the solution. Thanks for the investigation.
Cameron> It also works fine if you don't have the key in the apt secure
Cameron> key ring. I'm not sure why this is, but adding a successful key
Cameron> check seems to create this problem. There's almost certainly a
Cameron> bug in apt somewhere here, or maybe a couple, since I don't
Cameron> think apt should require a Packages file when it has no
Cameron> intention of downloading it.
Well, before posting here I did apt-get source apt and started wading,
I guess I'll do a bit more of that in copious spare time and report the
bug when I find it. Thanks again.
--
This line is completely ham.
Florent Rougon
Long before I heard about reprepro, I also wrote my own Python script to
manage my local and remote Debian repositories (and I'm still using it):
http://people.debian.org/~frn/fmdr
documented at:
http://people.debian.org/~frn/fmdr.txt
To follow the pattern on
http://wiki.debian.org/HowToSetupADebianRepository, it has these
features:
Automatic repositories: Yes
Incoming mechanism: not sure what this means; to upload a package, you
need to pass a .changes file to the --add option.
Pools: Yes
GPG signing: Yes
HTH.
--
Florent