When copying from a website it is easy for hidden text to be included in the clipboard. If you paste that into terminal it can be executed before you see the code. Including new line commands in the copied text will automatically execute the commands (in most terminal applications).
The best solution is to paste the clipboard content into something to view the text before pasting into clipboard. The best way is probably to recopy it. I use this double copy method to get rid of formatting I don’t want (when the clipboard includes things like font styling info you don’t want – not relavent when pasting into terminal but the pasting [into say vim, which won’t include the extra formatting details] and recopying part is similar). It may be possible to have text hidden (write it in a way where it won’t show up on the screen but is in the clipboard – using some tricky unicode characters or something).
Some people put # before pasting into clipboard but that only protects the first “line.” Any new lines could still be run without you seeing them.
The discussion warns against a malicious website intentionally creating a problem but if you paste in multiple lines there is also just the danger from the lines executing immediately when you wanted to edit the line before it was executed.
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.
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)
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]
Your bash profile lets you make edits that let you design how the cli works for you. One of my favorite edits is to let me set the scrolling back through my history be based on what I start typing. So, for example, I can type
and then use the up-arrow key and it scrolls through my cli history based only on those that start with cd
To add this to your .profile file (or put it in your .bash_rc file):
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.
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
To customize the look of the command prompt for Terminal in Ubuntu you can insert code into .bashrc (if you are having trouble with updates in .bashrc not working you may want to see if it is set in .profile – thus overriding your .bashrc). Those files are found in your user directory /home/[username]
will show you the current settings. You can make a change directly from the command line but it will only work for that session. For example:
[bash]PS1="\d\w $ "[/bash]
This is the code I have in my .bashrc related to the terminal prompt
[bash]# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
if [ "$color_prompt" = yes ]; then
unset color_prompt force_color_prompt[/bash]
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
If you don’t receive the email then you can troubleshoot what is going wrong.
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).
An authentication key allows your server to authenticate the computer you are using has the right key and should be granted access. This lets you use the key instead of a username and password when using ssh.
If you don’t already have a key on your local machine (look for a file named id_rsa.pub in your user home directory under the .ssh folder
will get you to the right directory) then you need to generate the key pair. On your desktop machine use:
Next you copy the file to your server. scp ~/.ssh/id_dsa.pub [user]@[server]:.ssh/
Rename the file on the server to authorized_keys2
[bash]mv id_rsa.pub authorized_keys2[/bash]
The key is for to authenticate your computer. But on the ssh login Ubuntu will look in the user folder. So if you also had user2 access to the server and tried to ssh into the server you would not be authenticated because it would look in user2/.ssh for the authorized key file and not find it. You can put the same key in any user folder on your server to have that user also be automatically authenticated.