Joe's Linux Blog Linux Admin tips and tricks

May 24, 2009

Qt4 RPMs for Centos 5

Filed under: Centos,Installation,qt — Tags: , — jfreivald @ 11:03 am

UPDATE; New post for the new packages: http://joseph.freivald.com/linux/2010/06/09/qt-4-6-3-and-qt-creator-1-3-1-1-updates-for-centos-5-5/

UPDATE: Nokia released Qt 4.6.0 and qt-creator 1.3.0 today.  The new RPMs are compiled and stored in the repository.  ‘yum update’ should be sufficient to grab the new ones.  I also changed the directory to reflect Centos 5.4 instead of 5.3.  Let me know of any issues.

–JATF

Want to get the Qt SDK working on Centos 5.3?

Quick instructions:

rpm -ivh http://software.freivald.com/centos/software.freivald.com-1.0.0-1.noarch.rpm
yum update fontconfig fontconfig-devel qt4 qt4-devel qt4-doc qt4-postgresql qt4-odbc qt4-sqlite qt-creator

Verify that the versions are coming from software.freivald.com and install. 🙂

Longer story:

All of the RPM’s described in this post are in a yum repository that you can access by installing this RPM.  It includes both x86_64 and i386 repositories that are automatically selected based on your architecture.

The first problem: the FcFreeTypeQueryFace problem that is very well described here, with a manual compile and upgrade way around it.  I thought I would go one step further and create an RPM.  Here is what I did:

I started with this source file from fontconfig.org and this SRPM from redhat.com, modified the spec file from the SRPM because of a changed config file location, and created these RPM files for you to install.

The second problem:  the QtSDK is built against several other libraries that are newer than provided with CentOS 5.3.  Rather than update those libraries, I’ve opted to compile RPMs for qt4 and qt-creator for CentOS 5.3. There are all new packages for them in the repository. They upgrade the shipped version (4.2.1) to the new version. They should be binary compatible, since theoretically Qt only breaks binary backwards compatibility on a major revision number change, but I don’t have any real way to test this. Feel free to post any problems you encounter.

The third problem: qt-creator isn’t included with the qt4 source.  I created it as its own package.  ‘yum install qt-creator’ to install it by itself.

Hopefully after installing the repository package, a

yum update

and everything should ‘just work’.

Oh, and feel free to use the ‘joewidgets’ and ‘joewidgets-devel’ packages.  They include some widgets that I use for other projects, primarily a back-port of the KLed widget to QLed that removed KDE dependancies, and a multi-state button with configurable colors for each state.  The ‘devel’ package includes designer plugins that also work in qt-creator.  Source for those are published in the srpms directory.

–JATF

May 14, 2009

Subversion, SSL and Apache for Secure, Passwordless, User-based repository access controls

Filed under: Configuration — Tags: , , , — jfreivald @ 9:54 am

I get tired of passwords.  Password here, password there, everywhere a password.

I am a systems designer who does a lot of admin out of necessity.  When I get tired enough of a task, I eliminate it.

I use subversion on several projects to track documentation, source, configurations and more.  All of my servers are SSL only, and use user certificates for identity verification.  Here’s what I did to make passwordless, user-based restrictions on Subversion:

First, make sure that SSL is working on your apache server (if you get a server error when you do an https request, but http://yourserver.com:443 works then SSL is not set up right).

Put the following in /etc/httpd/conf.d/subversion.conf:

<Location /yourSubversionWebLocation>
   DAV svn
   SVNParentPath pathToYourSubversionFolder

   AuthzSVNAccessFile /etc/httpd/yourSubversionAccessFile

   SSLRequireSSL
   SSLVerifyClient require
   SSLUserName SSL_CLIENT_S_DN_Email
   SetOutputFilter DEFLATE
</Location>

Some people might want to use SSL_CLIENT_S_DN_CN as the user name instead of the email, but in my case I use the CN to put the person’s real full name in the certificate, so the email worked out better.  Also, this way I can have jsmith@company1.com and jsmith@company2.com without a collision.  Use whichever works for your situation.

Put your repository access information into your SVN access file like this:

[shared:/]
user1@yourplace.com = rw
user2@yourplace.com = rw
user3@yourplace.com = rw
readonlyuser@yourplace.com = r

[user1:/]
user1@yourplace.com = rw

[user2:/]
user2@yourplace.com = rw

[user3:/]
user3@yourplace.com = rw

Generate your User SSL keys. I do it with a script (lots of stuff on the web on how to set up your own CA, so I’m not re-hashing it here):

#!/bin/bash

[ "$1" == "" ] && exit -1;

openssl req -config openssl.myconf.cnf -new -sha1 -newkey rsa:1024 -nodes -keyout private/$1.key -out csr/$1.pem
openssl ca -config openssl.myconf.cnf -policy policy_anything -extensions usr_cert -out certs/$1.pem -infiles csr/$1.pem
openssl pkcs12 -export -clcerts -in certs/$1.pem -inkey private/$1.key -out userp12/$1.p12

Be sure to use the same email addresses that you use in the SVN authorization file.

To access subversion from the command line, put the following into your .subverions/servers file.  Be certain that the file has strict permissions (chmod -R 0600 ~user1/.subversion; chmod -R 0600 ~user1/certs):

[groups]
myrepositories = <your server address>
[myrepositories]
ssl-authority-files = /home/user1/certs/<your CA file>.crt
ssl-client-cert-file = /home/user1/certs/user1.p12
ssl-client-cert-password = <user's certificate password>

To access it with a browser, import the CA and user certificates into the browser of your choice.  Users should then be able to select your web page and auto-magically get the right repositories with the right permissions.  No passwords needed.

If you want a pretty web interface for your repository, try out websvn.  Use the same SSL configuration information for your websvn.conf as you did for your subversion.conf, follow the install information for websvn, put your repositories into your config.php and you’re done.

Powered by WordPress