I had a handful of machines enrolled in a demo cluster. About half of them got shut down, and now I can’t SSH into them via Kerberos tickets. Here is my debugging notebook.
Troubleshooting a FreeIPA install:
Reply
Author Archives: Adam Young
Running PostgreSQL and Mysql Unit tests in Keystone
We don’t include the postgres or Mysql drivers inside the virtual env for Keystone, so you need to explicitly install them in order to run the unit tests.
firewall-d for FreeIPA
First hack at a script to open the ports needed by FreeIPA. On Fedora 18, running Firewall D, I ran the below script. Comments and corrections welcome.
IPTables rules for FreeIPA
I end up editing this so much, figure I’d post it here for all to use. This is the standard IPtables config file augmented with those rules required to let through the protocols supported by FreeIPA
# Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT #TCP ports for FreeIPA -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 88 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 464 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT #UDP ports for FreeIPA -A INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT
Trusts and OAuth
We had a recent IRC discussion about the design of Trusts and how it compares with OAuth version 1.
Continue reading
Trusts and Role Based Access Control for Open Stack
Bearer tokens are vulnerable to replay attacks. OK, so what are our options? Something where the user proves, via cryptography that they have the right to actually use the token. It doesn’t matter if it is X509, Kerberos, or something we cook up ourselves, it is going to resolve to proving you have the right to use that token.
If tokens must be validated by the owner, we effectively break the ability of Open Stack to hand around bearer tokens to get work done. We are going to have to get a lot of stuff right in order to keep from breaking things. Fortunately, we now have the tools to work around this, and to better secure an OpenStack system: Trusts and Role Based Access Control.
Continue reading
Keystone, MySQL and Fedora 18
It looks like the access model for MySQL has changed between F17 and F18.
openstack-db fails with a permission on the root user. However, the following works:
- As the keystone user (I suspect the openstack-db call made the keystone user, or maybe that is done by the RPM install?)
- run mysql, (no params, using the default identification, which I assume is PAM based?)
- create a user named keystone.
- and grant that user perms to create a db.
su - keystone mysql
create user 'keystone'@'localhost' identified by 'keystone'; grant all PRIVILEGES on *.* to 'keystone'@'localhost';
exit mysql and log in as that user:
mysql --user=keystone --password=keystone
Create the keystone database:
create database keystone;
Log out and run the dbsync
keystone-manage db_sync
Obviously, this leaves the DB User with too many permissions, but it is a start.
If I now try to run the command
openstack-db --service glance --init Please enter the password for the 'root' MySQL user:
Even setting the password in MySQL doesn’t work
UPDATE mysql.user SET Password=PASSWORD('keystone') WHERE User='root' AND Host='localhost';
[root@f18-keystone mysql]# openstack-db --service glance --init Please enter the password for the 'root' MySQL user: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) Failed to connect to the MySQL server. Please check your root user credentials.
I tried it with the unix password as well.
Note that I can connect using the following SQL Alchemy URL:
connection = mysql://keystone:keystone@localhost/keystone?unix_socket=/var/lib/mysql/mysql.sock
I think this is preferable to exposing TCP sockets around in the case that the Keystone server and MySQL server are co-located.
Meet the Red Hat OpenStack Team: Adam Young
We thought it would be a good idea to have a “Meet the Red Hat Open Stack Team” series of blog post. This is me.
Continue reading
Using Puppet to setup PostgreSQL for Keystone on Fedora
Using Puppet to manage software configuration makes sense. Setting up PostgreSQL support for Keystone development and testing has been my excuse to learn it.
sudo yum install puppet sudo puppet module install puppetlabs/postgresql
Then create a file /etc/puppet/site.pp
Put this line in it:
class { 'postgresql::server': }
postgresql::db{ 'keystone':
user => 'keystone',
password => 'keystone',
grant => 'all',
}
sudo puppet apply --verbose /etc/puppet/site.pp
Confirm that postgresql is running:
systemctl status postgresql.service
Should get you
postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled)
Active: active (running) since Thu, 03 Jan 2013 13:26:46 -0500; 43min ago
Process: 17529 ExecStop=/usr/bin/pg_ctl stop -D ${PGDATA} -s -m fast (code=exited, status=0/SUCCESS)
Process: 17553 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p ${PGPORT} -w -t 300 (code=exited, status=0/SUCCESS)
Process: 17545 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 17556 (postgres)
CGroup: name=systemd:/system/postgresql.service
├ 17556 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432
├ 17557 postgres: logger process
├ 17559 postgres: writer process
├ 17560 postgres: wal writer process
├ 17561 postgres: autovacuum launcher process
â”” 17562 postgres: stats collector process
Test we can connect to the PostgreSQL command line tool:
psql -h localhost -U keystone keystone Password for user keystone: psql (9.1.7) Type "help" for help. keystone=> \d
To run the Keystone unit test test against the database, alter the file /opt/stack/keystone/tests/backend_sql.conf. Comment out the sqlite connection line, and uncomment the postgresql line.
[sql] #connection = sqlite:// #To Test MySQL: #connection = mysql://root:keystone@localhost/keystone?charset=utf8 #To Test PostgreSQL: connection = postgresql://keystone:keystone@localhost/keystone?client_encoding=utf8 idle_timeout = 200
Then you can run the unit tests with
./run_tests.sh -N test_sql_upgrade
If the tests fail (and they will), they will leave the database in an unusable state. You can drop the database and recreate with puppet:
sudo su postgres -c "dropdb keystone" sudo puppet apply --verbose /etc/puppet/site.pp
A SQL upgrade script in Keystone
The SQL migration mechanism in Keystone is interesting enough to warrant some attention. If you need to modify the SQL database in any of the Open Stack projects, you are going to use a similar approach. Here is a step by step I have recorded of a SQL upgrade script I am writing for a feature in Keystone.
Continue reading