How to rebuild an RPM package

This is the 1st time for me to patch and rebuild an RPM package, when I tried to add Unicode Support on CentOS 5.4 with PHP and PCRE. I received some PHP warning message when I had the regex testing characters (‘\X’, ‘\pL’, etc) inside of a character class, such as ‘[\X-]‘. After I googled the Internet, I found that's because the Unicode Support is missing in the PCRE.

Note: This is an example which using PCRE SOURCE RPM package.



Since I downloaded PHP 5.3.1 and compiled manually by enable the configure option:

--with-pcre-regex=/usr

And PHP 5.3.x includes PCRE support built in; however, the yum package for PCRE is not built with Unicode support; so, need to download the rpm and patched according to this page:

http://gaarai.com/2009/01/31/unicode-support-on-centos-52-with-php-and-pcre/

This is needed for Unicode regexp support, so we can do input validation in a variety of character sets.

By default, at least on a Red Hat box, rpm uses /usr/src/redhat as the location of the %_topdir macro, which specifies where most of the work involved in building an RPM takes place.

You can and should change this; it is a good idea to make this a directory that you can write to with a non-privileged account, to avoid compiling and building packages as root.

Why?

A lot of commands get executed when building a package. Sometimes things go wrong. If you're root, important things may be damaged. A big mess may be made. I once (foolishly) rebuilt a proftpd package as root, and the "make install" stage blew up and left newly compiled files all over the place, whereas if I'd been a regular user, I'd have simply gotten a bunch of "permission denied" messages.

1. Anyway, the macro is easily changed by adding something like the following to ~/.rpmmacros:
   
   
   # Path to top of build area
%_topdir /home/you/src/rpm
   
   
   



2. If you have never worked on RPMs in this manner, you will need to create a few directories in which to work. I use a sub-directory in my homedir:
   
   
   #> mkdir -p ~/src/rpm
#> cd ~/src/rpm
#> mkdir BUILD RPMS SOURCES SPECS SRPMS
#> mkdir RPMS/i[3456]86 RPMS/noarch RPMS/athlon
   
   
   



3. Download the PCRE Source RPM, and install it:
   
   
   #> wget ftp://ftp.pbone.net/mirror/ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/pcre-6.6-2.el5_1.7.src.rpm

#>rpm -ivh pcre-6.6-2.el5_1.7.src.rpm
   
   
   Then install the following package from iso image if you didn't install them during the 1st time OS installation:
   
   
   #> rpm -ivh beecrypt-4.1.2-10.1.1.x86_64.rpm rpm-libs-4.4.2.3-18.el5.x86_64.rpm rpm-4.4.2.3-18.el5.x86_64.rpm elfutils-0.137-3.el5.x86_64.rpm elfutils-libs-0.137-3.el5.x86_64.rpm rpm-build-4.4.2.3-18.el5.rf.x86_64.rpm
   
   
   



4. Rebuild the PCRE RPM package and reinstall the new PCRE RPM package:
   
   opened up the ~/src/rpm/SPECS/pcre.spec file and found the following line:
   
   
   %configure --enable-utf8
   
   
   changed it to include the Unicode properties option:
   
   
   %configure --enable-utf8 --enable-unicode-properties
   
   
   Then saved and closed the file.
   
   



5. Rebuils the PCR RPM package:
   
   
   #> rpmbuild -ba ~/src/rpm/SPECS/pcre.spec
#> rpm -Uvh RPMS/x86_64/pcre-6.6-2.7.x86_64.rpm RPMS/x86_64/pcre-devel-6.6-2.7.x86_64.rpm –-force
   
   
   




6. Then run pcretest program, and you should see "Unicode properties support" shown in the result.
   
   
   $ pcretest -C
PCRE version 6.6 06-Feb-2006
Compiled with
UTF-8 support
No Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

   
   
   

I also found a very helpful guide that details this process out very nicely: How to patch and rebuild an RPM package.

Export a File System for remote NFS client

Export a File System for NFS system

This article presents the methods for preparing a set of directories that can be exported to remote NFS clients under Linux.

Under Linux this is can be accomplished by editing the /etc/exports file.


About the /etc/exports File

The /etc/exports file contains an entry for each directory that can be exported to remote NFS clients. This file is read automatically by exportfs command. If you change this file, you must run the exportfs command before the changes can be affected the way the daemon operates.

Only when this file is present during system startup does the rc.nfs script execute the exportfs command and start the service NFS (nfsd) and MOUNT (mountd) daemons.

Edit the exports file and add the following lines:

/dir/to/export host1.yourdomain.com(ro,root_squash)
/dir/to/export host2.yourdomain.com(rw,no_root_squash)

Where:

* /dir/to/export is the directory you want to export.
* host#.yourdomain.com is the machine allowed to log in this directory.
* The ro option mean mounting read-only. And the rw option mean mounting read-write.
* The root_squash option for not allowing root write access in this directory. And the no_root_squash option for allowing root write access in this directory.

For this change to take effect, you will need to run the following command on your terminal:

# /usr/sbin/exportfs -avr

Next thing is configure automatic mapping to this NFS system:

On your remote linux machine, edit the /etc/fstab and add the following line:

NFS_host_name:/dir/to/export /local/mapping/dir nfs hard,intr 0 0

Save and run the following command:

mount -t nfs -a

to mount all nfs entries in /etc/fstab with the corresponding options.

If you want to experiment with rsize and wsize parameters to get that last bit of performance.

NFS_Server_name:/dir/to/export /local/mapping/dir/ nfs rsize=8192,wsize=8192,timeo=20,retrans=6,async,rw,noatime,intr 0 0

Troubleshooting:

1. As with most things in linux, watch the log files. If you get an error on the client when trying to mount a share, look at /var/log/messages on the server. If you get an error like "RPC: program not registered" that means that the portmap service isn't running on one of the machines. Verify all the processes are running and try again.
   
   



2. The second problem has to do with username mappings, and is different depending on whether you are trying to do this as root or as a non-root user.
   
   If you are not root, then usernames may not be in sync on the client and the server. Type id [user] on both the client and the server and make sure they give the same UID number. If they don't then you are having problems with NIS, NIS+, rsync, or whatever system you use to sync usernames. Check group names to make sure that they match as well. Also, make sure you are not exporting with the all_squash option. If the user names match then the user has a more general permissions problem unrelated to NFS.
   
   

And if you cannot find the solution for your problem, please refer to the following url:

http://www.higs.net/85256C89006A03D2/web/PageLinuxNFSTroubleshooting

Note:

/etc/exports is VERY sensitive to whitespace - so the following statements are not the same:

/export/dir hostname(rw,no_root_squash)
/export/dir hostname (rw,no_root_squash)

The first will grant hostname rw access to /export/dir without squashing root privileges. The second will grant hostname rw privs w/root squash and it will grant EVERYONE else read-write access, without squashing root privileges. Nice huh?

Howto Fix Internal Server Error

Recently I encounter one problem: When running a Perl CGI (or Python) script on Fedora 10 machine, I saw the "Internal Server Error" message in my browser. The message said something like "please check the server's error-log for more information." and contact web server administrator.

I checked the Apache error log, since I am running Fedora, the error log file is located at /var/log/httpd/error_log. The error messages says:

[client 127.0.0.1] (2) No such file or directory: exec of '/var/www/cgi-bin/cgiscriptname.cgi' failed, referer: http://localhost/your.html

[client 127.0.0.1] Premature end of script headers: cgiscriptname.cgi, referer: http://localhost/your.html

I googled the solutions from Internet, but most of them are saying the permissions are not correct. But I changed the permissions for all the files and directories, but still doesn't work, and got the same error messages.

Finally I found the solution by checking the web server's configuration - httpd.conf which located at /etc/htttpd/conf/. By default in Fedora, the cgi-bin section is configured as following:


<Directory "/var/www/cgi-bin">
AllowOverride None<
Options None
Order allow,deny
Allow from all
</Directory>

So I noticed Options None was the one cause the problem. After I change it to the following:

Options ExecCGI

And restart the apache web service, the "Internal Server Error" message is gone. The scripts are running fine now.

By the way, I think the following tips might be useful in your cases.

1. The perl path or the python path in your script should be match your server environment settings.
   
   For perl, the header of your script should look like:
   
   
   #!/usr/bin/perl
   
   
   For Python, the header of your script should look like:
   
   
   #!/usr/bin/python



2. The second thing that you need to check is the permission of your CGI scripts.
   
   
   • Your home directory should have permissions of 701
   
   
   • Your .www (and any sub-directories containing you scripts) should have permissions of 701
   
   
   • Your CGI/Python scripts should have permissions of 701
   
   
   • Files that your CGI/Python script needs to read (for example an image file) should have permission of 604



3. The next thing is checking the owner and gorup of your CGI/Python script. Usually the CGI/Python script and the enclosing directory must have the same owner/group of your web server. You should go to /etc/httpd/conf/httpd.conf to check the web server owner. In Fedora, both should be apache by default.


4. The last thing that you might need to check is your scripts, some of them may transfered from Windows via FTP service. It should be transfered under ASCII mode. So you need to convert it to Unix line feeds by typing the following command:
   
   
   # tr -d '\r' <yourscript.py> yourscriptconv.py
   
   
   And run the new script which you converted.

Hope this will help you to solve your Internal Server Error Problem.

Adding your username to Sudo List in Fedora

Just trying new Fedora Release 11, but I cannot do software update by using the user which I created after first boot. The error message says "the user is now in sudo list". I think most of you might had same issue, and I found the following solution for you.


Log in as root.

su --login

Add your user to the sudoers file.

echo 'your_plain_loginname_here ALL=(ALL) ALL’ >> /etc/sudoers

Now the error message should be gone!

One more tips for those users had Linux box behind the firewall, and you want to download software via Text Internet. You can do it in 2 ways, one is permanently add the following line in the profile, or type the following line in the terminal window:

export http_proxy="http://your_proxy_server_address:port"

Enjoy!