Handy way to use su in Mac Terminal

 

 

I don’t recall where I  came across this information but passing it along should others need it or for myself to refer back to. I had tried in the past to us the Linux su command to login as a super user but it never worked. I think there are barriers built into to prevent this action.

What you can do to get around that behavior is to use the sudo command.

$sudo su

This will provide you access to the superuser without having to type in sudo every time if you have a number of commands.

Remove files by date using Linux Command Line

This command allowed me to remove all files in a directory that where older than 30 days.

rm -f  `find *.gz -type f -mtime +30`

You can see what you’ll be deleting first by running this command.

echo `find *gz -type f -mtime +30`

SSL CSR Generation on Linux Apache

Using the GoDaddy instructions on generating CSR.

One thing unclear in their instructions was where these would be after running. I appended a path to where my current Keys and CSR resided. [/etc/apache2/…]

Answered the questions when prompted.

Moved the CSR file to my workstation desktop. Opened the file in Notepad. Copied and pasted it into the GoDaddy interface and submitted.

restarting Apache on my Sandbox server

Took a couple of tries but here’s I did a restart of my apache.

/sbin/service httpd restart

SSL for Linux Apache2

Never having done a an SSL update for a Linux based Apache web server I approached this with some trepidation. It’s quite different from an IIS 6 update of which I’ve done many.
Complicating matters, Linux setups can vary from flavor to flavor. I was blessed with what seems to be a version that has the least amount usage in the wild, Gentoo.

The position that I’ve taken is in an office where the previous IT personnel had a huge disdain for any GUI management system that might make this process easier for someone coming in after them.

The biggest fear factor was that the SSL might have a passphrase that would be needed after restarting Apache. This might not only effect the site I was updating but any number of other sites with SSLs that might have the

Since this was a GoDaddy SSL I started out with the basics from the GoDaddy website

The gist of this was that I needed to swap out three files that were in /etc/apache2/ssl with the new files. That being the CRT, KEY and Intermediate CRT. I also wanted to copy the old files to another directory should I encounter any problems, I would have a fall back plan.

I checked the /etc/apache2/vhosts.d directory where the configuration files for the web site resided to verify that path and the file names that it would be expecting. I had to rename the intermediary file to match the one in the config.

About the passphrase. I found this article that explained the procedure to remove a passphrase from a SSL key file. As I found out later the other passphrase on the key files on this server had also been removed because when I restarted the Apache I did not get any prompts for them. Not having knowledge ahead of time if they did or didn’t have a passphrase set and if they did only being able to guess at what it might be this was a great relief. I used a number of websites to research using the openssl tool to remove the passphrase. I followed this one.

Specifically I used there model as shown only changing the name of the paths and files as needed.
Stripping the passphrase in a key to a new file.
openssl rsa -in /etc/httpd/conf/ssh.key/www.domain.com.key.2009 -out /etc/httpd/conf/ssh.key/www.domain.com.key.2009.no_password
Moving the original key file to a backup location
mv /etc/httpd/conf/ssh.key/www.domain.com.key.2009 /etc/httpd/conf/ssh.key/www.domain.com.key.2009.needs_password
Renaming the passphrase stripped key file
mv /etc/httpd/conf/ssh.key/www.domain.com.key.2009.no_password /etc/httpd/conf/ssh.key/www.domain.com.key.2009

I did this all in a staging area and not the actual path.

I also used the key and CRT check commands to verify that my file group was matched.
openssl rsa -noout -modulus -in /etc/httpd/conf/ssl.key/www.example.com.key.2009 | openssl md5
4cb1f8bfbb0a1467f99120886559f7f8

openssl x509 -noout -modulus -in /etc/httpd/conf/ssl.crt/www.example.com.crt.2009 | openssl md5
4cb1f8bfbb0a1467f99120886559f7f8

With all my files in order in my staging directory and the previous SSL files copied into a backup directory I copied my new ones into the working SSL directory.

I used the advise of this site that suggested running a configtest ahead of doing the restart.

# test the configuration first!!
root# /etc/init.d/apache2 configtest

It checked out ok so I then ran the restart.

if the configuration is ok then restart apache

root# /etc/init.d/apache2 restart

Everything worked!!! No passphrase prompts on restart!!!

Yeah!!!

yep

howdy

Finding info from a Certificate Signing Request (CSR)

I have recently inherited many web sites in my new job. I had the task of renewing the SSL for one of these sites. This is my first foray into LAMP based setup with no control panel. The SSL was on auto renew so I got the email from GoDaddy indicating it was renewed. I still needed to get the CRT and install it on the server. In the process I was prompted to use the previous CSR. I thought heck yeah. One less thing to figure out how to do. I was able to download my needed files and was ready to go but I thought I should read up on this bit more as I’ve never did an SSL in a LAMP environment.

Turns out that the CSR might contain a Passphrase. If it did and I don’t have access to the correct passphrase the site will not start up. Not good.

It looks like my option was to go to the GoDaddy site and Re-key the CSR. Another problem was that since I just started here I might not know the particulars of the CSR such as Organization (the company has merged with others so just using the one that employed me not work).

I came across this command to use with OpenSSL, the program used for Linux based SSL setup, to find info about the CSR.
openssl req -text -noout -verify -in namedomain.com.csr
There is also this handy web tool. http://www.sslshopper.com/csr-decoder.html

This provides the Common Name: Organization: Locality: State: Country: etc.

Find Linux Distribution Command

At command prompt type: lsb_release -a

I can verify this works with CentOS.
Here is the example output.
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:g
raphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 6.4 (Final)
Release: 6.4
Codename: Final

This does not work for all version of Linux. I also have a Gentoo server. I used the following to get the information.
cat /etc/*-release

Displays the following info.
Gentoo Base System release 1.12.11.1

WordPress automatic update goes wrong with 404 and URL of wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2F

I haven’t entered any post lately and when I jumped on the admin to enter one I got the nag screen about updating WordPress. Foolishly without thinking I just did the automatic update. I normally go through the GoDaddy upgrade script and have not had problems with it but launching this update from the admin I could not enter login to the admin. I kept getting a 404 error page and the URL was wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2F.

The actual blog did not go done and seem to survive the upgrade. It was only the admin that was not accessible.

Doing some looking around on the web for the simplest way to fix this I saw post about doing a manual install over the update. A number of other suggestions that seemed to much effort. I got a hint from one of the post indicating copying files over similar to a manual install.

Since the page not found was coming from the wp-admin directory I took a gamble and downloaded WordPress 3.4.2 to my local machine. I then uploaded only the wp-admin over my upgraded site. Presto error page is gone.

Upon doing this when logging into the admin page I was prompted to upgrade the WP database. I did and all is well.

Screen Captures In Terminal Services

I spend a lot of time in Terminal Services working on any number of computers. Frequently I’m two levels deep in it. That is I’m remoting into a machine and then remoting into another one from that. One of the annoyance with our current system vendor is that they know so little about their system that they require extensive screen shots for any and all issues.

To accomodate while being in terminal sessions I found this person’s blog to be helpful.

http://www.christiano.ch/wordpress/2010/08/21/capture-alt-print-screen-focused-window-in-rdp-session-in-clipboard/

The crux of it is to use CTRL-ALT-Minus to accomplish this. I have tried it and it works like a charm.

Top