Locking and Unlocking a User in Ubuntu

Posted on February 19, 2016 by curiouscat

To lock a user in Ubuntu sudo usermod –expiredate 1 [username] Substitute the user’s username where username is shown below.

[code]sudo usermod –expiredate 1 username[/code]

This also can be shortened to

[code]sudo usermod -e 1 username[/code]

To unlock a user

[code]sudo usermod -e -1 username[/code]

This will disable the user both from accessing via password and from accessing via a private key.

You can also expire a user at a future date using

[code]sudo usermod -e YYYY-MM-DD username[/code]

To expire a password and force a user to enter a new password

[code]sudo passwd -e YYYY-MM-DD username[/code]

How to Manually Run Cron Tasks

Posted on September 27, 2015 by curiouscat

To manually run cron tasks you can use the run-parts command in Linux.

So to run your cron-weekly, for example, to test that a fix you just made runs without error (this is what I just did, in fact)

run-parts /etc/cron-weekly

run-parts will run all the executables in a directory (you must point at the directory). So if you have several files in cron-weekly to run, you can’t just point to one of the files.

You may run into environmental differences running the script as a different user than the cron test runs at, so you can run as that user if needed. You need to be aware this is a quick and simple way of testing part of the process but it doesn’t do a perfect job of testing if it works as a cron task. But it will let you catch some failures quickly and fix them in time for the actual cron task to run. So do check that the everything works after the real cron job runs.

This is just the kind of thing I said I would put in this blog. Simple stuff but things I forget – so I put it here to remember and maybe help out others, like me, that need really basic tips.

If you have a cron task item (or have setup the whole task this way) that is just a script and you just want to test that 1 item you may run the script directly. For example (for a Linux shell script):

sh /etc/cron.weekly/your_crontask_script.sh

VPS, Cloud and Server Colocation Options

Posted on October 23, 2014 by curiouscat

Finding the right place to host your content is important. Thankfully their are several excellent providers. For virtual private servers (one server shared with multiple virtual servers) Linode and DigitalOcean. And there are lots of good choices but those two are widely appreciated for excellent service at a good price.

AWS ec2 (the Amazon elastic cloud) is not great for minimal hosting in my opinion – it adds extra complexity and is likely more expensive. But it is a great solution when you have the resources to manage it and you have significantly variable demand. Because of the ability to add capacity on the fly as you need it you can maintain a low baseline and add capacity only as needed and drop that extra capacity as soon as it isn’t needed.

Rackspace is another good option for hosting. Rackspace and AWS are often used for very large applications and sites but Linode and Digital Ocean also can serve those needs and provide similar options to add capacity on the fly.

All of these options require you to manage your server (which may well be a virtual server – that is just a portion of a actual physical server that you control).

Rackspace also offers co-location where your physical server is put in their network operation center with electricity; cooling; network and internet connections; and physical security managed by them and the server managed by you.

As colocation has evolved what is included and to what level things like physical security and redundancy are dealt with have evolved. It has become quite complex to understand all the options for those organizations that need more than a simple virtual private server. As often happens when their is a business need, people offer solutions. And there are companies that specialize in helping you find the best colocation options for your needs.

Today the cloud options have led many organizations to eliminate (or greatly reduce) there own network operations centers and colocation needs. But cloud options are not always the right choice. And for some needs cloud options are not appropriate yet (mainly due to security or legal issues stemming from security concerns).

Managing your own servers with a colocation arrangement can be significantly cheaper than cloud hosting options (especially if you don’t need to massively increase capacity to deal with short term bursts of demand). Of course, technology continues to change so quickly it is hard to predict what the future will bring.

Service quality is absolutely critical for colocation. While saving money is important, the reason colocation was selected (over virtual private servers or the cloud) is normally how critical the function was. Using experts to help sort through the options and assure the quality of service of provides is wise.

Updates Needed When Upgrading from Apache 2.2 to 2.4

Posted on August 17, 2014 by curiouscat

I updated from Ubuntu 12.04 to Ubuntu 14.04 on a virtual private server.

When you do that update, Apache is updated from 2.2 to 2.4. Certain changes mean that until you update the site-available configuration files no web sites will work.

The quick checklist of what you have to do for each configuration

update the file to add or edit the directory details (where /var/www/curiouscatnetwork.com/public_html/ is the path to the website files on your server)
[bash]<Directory /var/www/curiouscatnetwork.com/public_html/>
Require all granted
</Directory>[/bash]
Remember if you have details needed for WordPress those instructions need to remain. I didn’t have a Directory area listed on my non-Wordpress sites.
The files now need a .conf extension so move the rename/move the files to the new name
[bash]sudo mv curiouscatnetwork.com curiouscatnetwork.com.conf[/bash]
Enable the new configuration
[bash]sudo a2ensite curiouscatnetwork.com.conf[/bash]
Reload apache to reload the new configuration
[bash]sudo service apache2 reload[/bash]

More details from Linode.

The upgrade to Ubuntu 14.04 LTS was interrupted (I quit a window using the wrong command – oops). Luckily it wasn’t a big deal. I was able to delete the lock file.

[bash]sudo rm /var/lib/dpkg/lock[/bash]

Then trying to update again

[bash]sudo apt-get dist-upgrade[/bash]

gave a message telling me what command to use to have the upgrade continue.

[bash]sudo dpkg –configure -a[/bash]

which seemed to work fine.

Making Sure You Don’t Run Out of Space on Your VPS

Posted on February 6, 2013 by curiouscat

Over the years I have had web sites I work on go down because the server ran out of space (when I wasn’t responsible for the system administration). Well today I had it happen for some sites on one of my servers.

I have a remote monitoring service so I was notified when the sites were unavailable. Looking in the error logs I could see I ran out of space, which is a fairly lame error to make, I think. I cleared up some space quickly and things were in working order again.

A few tips from this experience. To see data on space used and available space from the command line (linux/ubuntu) use the df command.

[bash]df[/bash]

You could check that occasionally to see if anything strange is going on. But it is better to use something like Nagios to monitor the server and provide notice if usage goes past certain points is wise (75%, 80%…).

I found a nice way to find large files (that may be possible to delete to free up space)

[bash]sudo find . -mount -ls | awk ‘{print $7, $11}’ | sort -rn > large_file_list[/bash]

If you get an error with the file creation, you can log in as root (su) or create the file first and then it can overwrite the existing file.

It is smart to have log rotate setup for logs. I didn’t have it setup for every log. To create a file to keep track of all your logs for domains you can do the following. Create a file in the logrotate directory so it is run per your settings.

[bash]sudo vim /etc/logrotate.d/virtualhosts[/bash]

This article from Slicehost provide details on options, a simple setup is to include text such as this in the file created in the line above.

[bash]/var/www/domain1.com/logs/*log /var/www/domain2.com/logs/*log {
rotate 14
daily
compress
delaycompress
sharedscripts
postrotate
/usr/sbin/apache2ctl graceful > /dev/null
endscript
}[/bash]

Continue reading →

ModSecurity – Adjustments for WordPress

Posted on January 6, 2013 by curiouscat

How to secure an Ubuntu 12.04 LTS server – Part 1 The Basics is a great resource to secure a VPS.

Mod_Security is a web application firewall. I found a couple things to add to my servers.

The same site includes a very good guide to installing it (you also may well want to whitelist Googlebot, instructions in the link). However it blocked my access to one of my sites. You end up just getting the message:

“Forbidden

You don’t have permission to access / on this server.”

There are tips on some edits to include when using WordPress on an Apache server with modsecurity.

One simple action is to include

SecRule SERVER_NAME “[your-domain.com]” phase:1,nolog,allow,ctl:ruleEngine=off

[bash]SecRule SERVER_NAME "code.curiouscatnetwork.com" phase:1,nolog,allow,ctl:ruleEngine=off[/bash]

on the bottom of modsecurity.conf which is found /etc/modsecurity (for me, on Ubunutu 12.04). Then restart Apache

[bash]sudo service apache2 restart[/bash]

and see if the problem goes away. If it does then you have a very good indication modsecurity was blocking access and can continue to narrow the scope of the problem by adding the WordPress whitelist rules in the link above.

Another note, service apache2 start, failed in a non-obvious way to me anyway. For me if I use sudo it works fine. If I don’t it gives odd errors which lead me on a 10 minute wild goose chase before remembering to try sudo.

Upgrading VPS Web Server from Ubuntu 10.04 to 12.04

Posted on October 15, 2012 by curiouscat

I am not a “real” system administrator but I manager sever VPS servers for my own web sites. This is what I did to update from Ubunutu LTS 10.04 to Ubunutu VPS 12.04.

I already have all the code and databases backed up, off the server, regularly. I backed up various things to another machine: sites-available files, cron directories, .bashrc, .profile, keys.
I tried running the preferred upgrade command
[bash]do-release-upgrade[/bash]

But got the message

-bash: do-release-upgrade: command not found

Then I ran

[bash]sudo apt-get install update-manager-core[/bash]

Then I was able to run [bash]sudo do-release-upgrade[/bash]
Which resulted in this somewhat scary message

This session appears to be running under ssh. It is not recommended to perform a upgrade over ssh currently because in case of failure it is harder to recover.

If you continue, an additional ssh daemon will be started at port ‘9004’.
Do you want to continue?

I look around on the web for advice. What’s the risk of upgrading over SSH? seems a good recap. I then continued. I then got this message

To make recovery in case of failure easier, an additional sshd will be started on port ‘1022’. If anything goes wrong with the running ssh you can still connect to the additional one.
If you run a firewall, you may need to temporarily open this port. As this is potentially dangerous it’s not done automatically. You can open the port with e.g.:
‘iptables -I INPUT -p tcp –dport 1022 -j ACCEPT’
12 minutes after the upgrade started, the download was complete and I got a message to decide if I wanted to manually approve every restart required or just automatically approve them all. I chose the option to have all restart automatically.
Then lots of files were installed and I was asked about various files; where I (or some script) had changed (or deleted) the default file and now the upgrade wanted to replace the existing file. I had to guess what to do in those cases. They let you look at the diff between your existing file and the proposed overwrite. I think I would like it if they default behavior was to create a backup of the file in that same directory (you choosing whether to set your file or the updated file as active).

The entire process took exactly 30 minutes, with the system restarting in Ubuntu 12.04.

Thankfully the upgrade seems to have gone without causing any problems. This is normally the case. But, even with a very small likelihood of encountering issues it is worrisome as those issues might pose some serious problems. Especially for someone with very limited system administration ability.

I am extremely thankful for all the programmers that created the code to make this process so straightforward and reliable.

[bash]lsb_release -a[/bash]

lets you see the current Ubunutu version you are running.

When I updated a server that had Ruby on Rails applications everything almost worked fine. Passenger was unable to load the application talking about

libmysqlclient_r.so.16: cannot open shared object file: No such file or directory – /usr/local/rvm/gems/ruby-1.9.2-p290/gems/mysql2-0.3.11/lib/mysql2/mysql2.so

I was able to find the solution to that issue was to uninstall the mysql2 gem and then run bundle update: which worked great. The uninstall would work for me unless I was actually root (sudo didn’t work), so I used su to login as root and then

[bash]gem uninstall mysql2[/bash]

Then I went back to being my other user ran bundle update

[bash]bundle update rake[/bash]

Then everything was working fine.

Testing Email Using The Ubuntu CLI

Posted on April 17, 2012 by curiouscat

For a Virtual Private Server (VPS) or any other web or other server you should have alerts sent by email for various things. So for example if you automate security updates for an Ubuntu web server you want to be notified if there is some issue with the automatic update.

In order to check and be sure email is setup and working on the sever there is simple command line code to use:

[bash]mail -s Test[/bash]

you then get a prompt to enter

To: [enter the email and press return]

Cc: [press return]

then a blank where you can type in any text you want in the body of the message.

Then you send the message with by pressing CTRL-d

[bash]CTRL-d[/bash]

If you don’t receive the email then you can troubleshoot what is going wrong.

Keeping Your Hosted Ubuntu Web Server Software Up to Date

Posted on April 16, 2012 by curiouscat

To setup automatic security updates follow the instructions from Ubuntu.

To run security update manually

[bash]sudo unattended-upgrade[/bash]

A full update of all packages can be done using the follow, remember this may create some issues is one update makes something else you have no longer work properly. You should test to make sure things all work after the updates (for production systems obviously you should test things before [first updating the staging server to make sure the updates don’t cause any problems] and after the updates).

First update the local package index (to find what needs to be upgraded).

[bash]sudo apt-get update[/bash]

Then upgrade the software.

[bash]sudo apt-get upgrade[/bash]

Checklist: Setting Up a New Domain on VPS

Posted on May 5, 2011 by curiouscat

Two great hosts for Ruby on Rails are Slicehost and Linode. With these hosts you fully manager your virtual private server, installing the operating system, modifying apache (on Ning…), etc.. I use Ubuntu as the operating system and Apache as the web server.

If you are moving a domain from elsewhere it can be wise to reduce the TTL time to say 5 minutes a few days before you make the switch. This is make the change propagate across the internet more quickly.

And DNS entry on your profile (login to your, for example, Linode account)
Add a new file for /etc/apache2/sites-available/your_site_name.com

[bash]sudo nano /etc/apache2/sites-available/example.com[/bash]

The file would look something like this: with your ip in place of 8.8.8.8

ServerName example.com ServerAlias www.example.com ServerAdmin your_gmail+example.com@gmail.com DocumentRoot /u/apps/example.com ErrorLog /u/apps/example.com/error.log

ServerAdmin is the address Apache will use to send error messages to. Using gmail and the + option lets you use one gmail account and just use rules to filter all your sites.

create the directories needed on your server
enable the site (for apache)
[bash]sudo a2ensite example.com[/bash]

You should see the file you created /etc/apache2/sites-available/example.com now also at /etc/apache2/sites-enabled/example.com

Test the site out to make sure the setup is working properly. Create a index.html page and just verify the page is displayed. Change your local hosts file to point to your server IP address for the new domain you created. If not, take steps to get this to work, before continuing with the rest of the checklist.
copy over the site – if you are moving the site from elsewhere
remember to move the database over, if the site relies on a database
restart apache
[bash]sudo /etc/init.d/apache2 restart[/bash]

You can test the site out, before updating the DNS, by changing your local hosts file to point to your server IP address for the new domain you created.

Resources: Install the Apache 2 Web Server on Ubuntu 10.04 LTS (Lucid)

Curious Cat Code

Tag Archives: VPS