Skip to content
This repository has been archived by the owner on Jul 29, 2018. It is now read-only.

Issues installing under CentOS 6.4 #15

Open
krusynth opened this issue May 12, 2014 · 22 comments
Open

Issues installing under CentOS 6.4 #15

krusynth opened this issue May 12, 2014 · 22 comments

Comments

@krusynth
Copy link

I struggled all weekend to get this up and running, but still can't get the keygen step to run without error. Here's a summary of what I've done, based on Dave's work in the dockerfile:

sudo yum update -y

sudo yum install -y wget zlib-dev openssl-devel sqlite-devel bzip2-devel rng-tools

wget https://www.python.org/ftp/python/2.7.6/Python-2.7.6.tgz


cd
tar -xzf ~/Python-2.7.6.tgz 
cd Python-2.7.6
./configure --prefix=/usr/local 
sudo make
sudo make altinstall

cd
wget --no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz
tar -xzf setuptools-1.4.2.tar.gz
cd setuptools-1.4.2
sudo /usr/local/bin/python2.7 setup.py install

cd
wget https://raw.github.com/pypa/pip/master/contrib/get-pip.py
sudo /usr/local/bin/python2.7 get-pip.py 

sudo /usr/local/bin/pip2.7 install -r requirements.txt 



python2.7 manage.py gpginit

I'm using python 2.7 because there appears to be 2.7-requiring packages among those requirements.txt, but I can't remove 2.6 entirely because yum needs it. I'm also having to run rngd from rng-tools (not listed above), since I'm running on a Vagrant box, and lack of hardware means it can't generate enough random bits to fill PGPs needs.

The error is:

Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/local/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/local/lib/python2.7/site-packages/gnupg/_meta.py", line 541, in _read_response
    result._handle_status(keyword, value)
  File "/usr/local/lib/python2.7/site-packages/gnupg/_parsers.py", line 859, in _handle_status
    raise ValueError("Unknown status message: %r" % key)
ValueError: Unknown status message: u'ERROR'

but it still says that the key is being generated. Further debugging shows that the error code is 65535, which I think may have something to do with the non-user homedir?

@waldoj
Copy link
Member

waldoj commented May 12, 2014

lack of hardware means it can't generate enough random bits to fill PGPs needs

This is fascinating.

@krusynth
Copy link
Author

I know, right? I noticed the keygen was hanging forever, and assumed it was a lack of RAM issue. Once that didn't fix it, I found this:

http://www.howtoforge.com/helping-the-random-number-generator-to-gain-enough-entropy-with-rng-tools-debian-lenny

And then a bunch of threads saying you can generate entropy via keyboard, mouse, and harddrive spinning. Lack of all of these means it doesn't generate bits? I'm no expert on entropy or anything, so I might be misconfusinating the issue.

@waldoj
Copy link
Member

waldoj commented May 12, 2014

This calls for Lavarand!

@krusynth
Copy link
Author

If Lavarand doesn't end up matching a curve of e I'd be astounded. Everything is e. ;)

@mtigas
Copy link
Member

mtigas commented May 12, 2014

lack of hardware means it can't generate enough random bits to fill PGPs needs

Hm... For dev environments maybe we should default the settings to use a small PGP key size (like 1024bit) instead of the very paranoid 4096bits currently set in the gpginit commandthen have the local_settings.py override this for production environments. Should save people a lot of grief.

@krues8dr: If you want to see if this helps out your Vagrant box: can you try editing /authentication/authapp/management/commands/gpginit.py, changing the key sizes down to 1024, then try setting up the GPG key again?

You could also try to install haveged which artificially increases the Linux entropy pool (which is unsafe for a user-facing website in production, but good enough for a dev VM).

@krusynth
Copy link
Author

Thanks, but I think I've already got past that point with rng-tools and am no longer receiving the lack-of-entropy error. This is a different error, and I'm still receiving it with 1024 bits. Again, I think this is related to the different homedir being used for key generation, or maybe needing gpg-agent ? I'm not entirely sure.

@mtigas Have you gotten this to run on anything outside of OS X? I know @vzvenyach is running it on Ubuntu with no problems. Could be something of the selinux variety as well, or other RHEL-specific concerns, due to the better security model.

@mtigas
Copy link
Member

mtigas commented May 12, 2014

@krues8dr Can't test it out again until I get home later today — but no reason why it shouldn’t run smoothly on Linux, too. (For other VMs, I've definitely had crypto issues unless I set up haveged — not sure how well rng-tools + system PRNG compare to using that to fill.)

Might want to nuke the gpgdata directory and try doing the init again. Also, setting GNUPG_BINARY should be to the actual GPG binary and not a symlink (i.e. GNUPG_BINARY="/usr/bin/gpg2" instead of "/usr/bin/gpg")

(Also helpful to help you get up and running: python2.7 manage.py gpginit | grep -e "^GNUPG_IDENTITY" >> local_settings.py.)

Will be back with more later tonight.

@vdavez
Copy link
Contributor

vdavez commented May 15, 2014

Just wanted to let you know that haveged worked wonders on an EC2 instance.

@krusynth
Copy link
Author

krusynth commented Jul 2, 2014

Hey guys, I've tried using haveged but still getting the same error on CentOS. I tried launching it with -w 4096 and also decreasing the key size in /authentication/authapp/management/commands/gpginit.py but it hasn't resolved the issue.

@vdavez
Copy link
Contributor

vdavez commented Jul 2, 2014

What version of centos?

@krusynth
Copy link
Author

krusynth commented Jul 2, 2014

@vdavez
Copy link
Contributor

vdavez commented Jul 2, 2014

Right-o. Will try tonight.

@krusynth
Copy link
Author

krusynth commented Jul 2, 2014

Thanks @vzvenyach ! Here's the Vagrantfile I'm using: https://gist.github.com/krues8dr/4a1528f05c5216e983b0

@vdavez
Copy link
Contributor

vdavez commented Jul 2, 2014

Thinking out loud. Any chance it's the 512 memory?

@krusynth
Copy link
Author

krusynth commented Jul 2, 2014

I tried bumping that to 2Gb but no luck.

@vdavez
Copy link
Contributor

vdavez commented Jul 2, 2014

Harrumph. Ok. Will give it a go when I get to a PC? Any progress on the documents view?

@krusynth
Copy link
Author

krusynth commented Jul 2, 2014

Nope, spent all my time on that so far. I think I'll need that to get rolling, or is there already some fixture data I can load to get up and running?

@vdavez
Copy link
Contributor

vdavez commented Jul 2, 2014

Right. One other ask. Can you use ipython to give more debug details?

@vdavez
Copy link
Contributor

vdavez commented Jul 3, 2014

Can you run this command? cat /proc/sys/kernel/random/entropy_avail

@krusynth
Copy link
Author

krusynth commented Jul 3, 2014

Using pdb to debug isn't getting me anywhere - it's occurring in a separate thread and for some reason it's not letting me drill down. Weird.

I've got 4096 for entropy_avail; I added setting the -w flag in the haveged init script to bump it up from 1024.

@vdavez
Copy link
Contributor

vdavez commented Jul 3, 2014

Huh. It's hanging for me too. I've done this on several ubuntu machines now and it works fine, but CentOS definitely is behaving differently. Will keep banging away... just an update

@vdavez
Copy link
Contributor

vdavez commented Jul 3, 2014

Couldn't figure this out, but made headway on the documents view...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants