Sigul – Problems and Troubleshooting

In this post I will talk about problems that I ran into while setting up sigul. Some of these are pretty stupid mistakes on my part, but I’m putting everything up here anyway.

When you are getting the key to place in, you run the gpg command to get it. The gpg command will output a key in UPPERCASE, change this key to lowercase or the entire process will never work.

Sigul Server and Bridge /tmp
Check how much space the bridge and server have. The server needs space equal to the largest package * 2. It needs this because it will download the package then make a second copy that is signed, delete the old one, and then transfer the signed copy to the bridge. The bridge only requires space equal to the size of the largest package. STOP you are not done, there is a trick, this space must be assigned to the /tmp directory, if it is not you will get EOF Errors all over the place. Run the df -h and check tmpfs size.

Server /tmp = largest package * 2
Bridge /tmp = largest package

You will get different EOF Errors depending on if it failed on the bridge or server, they will not be descriptive and will say something about DoubleTLS or failed on outer stream.

Verify MD5 checksum of rpm files
You must make sure the MD5 Checksum of rpm files matches the one that is inside koji’s database. So if a rpm fails for an unspecified reason make sure that the rpm checksum matches the koji db one.

Get the checksum:

rpm -Kv file.rpm

Get the koji db checksum:

psql -c "select payload_hash from rpminfo where rpmname = 'name_of_rpm';" | cat

If they are not equal to each other then you must figure out if the rpm is corrupt, the koji db is incorrect, and make sure that these 2 things match. When they match will work without errors(hopefully).

Connections timing out
This showed up when we tried to go from working test sign runs with a small amount of packages to a full sign run with –inherit and lots of packages. Instead of working it failed on all packages. What needs to be done is, modify the file:


change the DEFAULT_TIMEOUT variable to something higher like 60 or even 300. After this it should stop the timeout issues.

Unsupported format of database
This sometimes shows up in Sigul while you are trying to create databases, or access them. This usually means you forgot something basic, such as the directory is wrong, bad permissions, or does not exist. Make sure it does exist and everything is right.


About oatleywillisa

Computer Networking Student
This entry was posted in SBR600 and tagged , , , , , , , , , , , . Bookmark the permalink.

6 Responses to Sigul – Problems and Troubleshooting

  1. Pingback: Sigul – Setting up a Sigul Client | Andrew Oatley-Willis

  2. Pingback: Sigul – Connecting to server/bridge | Andrew Oatley-Willis

  3. Pingback: Sigul – How to Sign | Andrew Oatley-Willis

  4. Thank you for posting these blog entries on Sigul. Quite useful information. Did you have any issues with gpg? In our setup, after issuing a new-key request from a client, the server logs the ‘initial-key-admin’ request, sits for about 15 minutes and finally logs ‘Unrecognized GPG stderr: “can’t connect to `/var/lib/sigul/gnupg/S.gpg-agent’: No such file or directory”‘. If we manually start gpg-agent as the sigul user and verify permissions on the S.gpg-agent socket, the request still takes about 15 minutes and fails with ‘Bad passphrase’.

  5. Informative piece of information shared by you. I would like to thanks for you for sharing this blog online.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s