Following a tutorial where you’re supposed to add a repository with apt-add-repository but the command isn’t found? You can install it by doing the following:
sudo apt-get install software-properties-common python-software-properties
Then re-run the apt-add-repository command and it should work!
So, after a few failed attempts at installing the Aegir 3 Drupal control system we hit upon this “recipe” as what works for us currently on a fresh install of Debian 8 Jessie or Ubuntu 14.04.
This assumes you are logged in as root. First, update and upgrade your system.
apt-get update && apt-get upgrade -y
For the version of OS that currently gets installed with a fresh Binary Lane VPS we also need to update the base system. We like to use aptitude for that; while we’re installing aptitude, we might as well install the other thing that Aegir needs to install properly:
apt-get install curl sendmail aptitude -y
Upgrade:
aptitude safe-upgrade -y
Now, we need to install the database server. We use MariaDB.
apt-get install mariadb-server -y
One that’s done – you will be prompted to enter a root password for the database – we run the following command:
mysql_secure_installation
Don’t worry about changing the root password now that you have already set one, but delete the test database when prompted, disable anonymous access and flush privileges. Now we can install Aegir, nginx, php5-fpm etc.:
echo “deb http://debian.aegirproject.org stable main” | sudo tee -a /etc/apt/sources.list.d/aegir-stable.list
curl http://debian.aegirproject.org/key.asc | sudo apt-key add –
apt-get update
apt-get install aegir3 aegir3-provision aegir3-hostmaster nginx php5-fpm
Enter the hostmaster URL – usually the fully qualified domain name. Enter the database root password once for provision and once for hostmaster.
Assuming all of the above has gone well, you should be given a one-time-login link in your terminal at the end of the install process, e.g.:
http://aegir.example.com.au/user/reset/1/1446598196/Nw4T4yd25IWEngCP2d2A_Ck3XslBiobnhbuNzXU4/login
Now, before using that run the following:
visudo
Add this to the end of the file:
Defaults:aegir !requiretty
aegir ALL=NOPASSWD: /etc/init.d/nginx
This gives Aegir – the aegir user – permission to restart nginx without requiring a sudo password.
Test this works by doing the following:
su – aegir
sudo /etc/init.d/nginx restart
What you want to see then is this:
* Restarting nginx nginx
[ OK ]
Then:
vim /etc/nginx/nginx.conf
Comment out by putting a # in front of:
# tcp_nopush on;
# types_hash_max_size 2048;
# error_log /var/log/nginx/error.log;
Reboot, and use the one-time-link. You should be logged in fine and now can use Aegir!
Shellshock is quite a serious security hole found a couple of days ago in Bash; to check whether your Ubuntu server is vulnerable run the following in a terminal:
env VAR='() { :;}; echo Shellshock vulnerable!‘ bash -c “echo Bash Testing”
If your system is vulnerable, you will see:
Shellshock vulnerable!
Bash testing
If it is not vulnerable, you will see:
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR’
Bash testing
If you are vulnerable, you can update bash by running the following:
sudo apt-get update && sudo apt-get install
--only-upgradebash
Once the update has finished, run the code to check your vulnerability again and it should be sorted. NOTE! Only the currently-supported versions of Ubuntu will get the bash update – if you are running anything older (e.g. 13.04, 13.10 or anything older that isn’t a still-supported LTS release) you will need to update your Ubuntu install to have the above work.
If you have a lot of virtual (or real) machines running Debian or Ubuntu and a limited internet connection, it can make a lot of sense to use apt-cacher-ng to create a local cache of the packages you use so that they are only downloaded once. The current version of apt-cacher-ng can also help out with yum repositories!
On CentOS, edit /etc/yum.conf and add:
proxy=http://[ip-of-your-local-apt-cacher-ng-server]:3142
If you have changed the default port of apt-cacher-ng from 3142, you will need to modify that. Our example file:
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=5
bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=http://bugs.centos.org/bug_report_page.php?category=yum
distroverpkg=centos-release
proxy=http://10.1.1.12:3142# This is the default, if you make this bigger yum won’t see if the metadata
# is newer on the remote and so you’ll “gain” the bandwidth of not having to
# download the new metadata and “pay” for it by yum not having correct
# information.
# It is esp. important, to have correct metadata, for distributions like
# Fedora which don’t keep old packages around. If you don’t like this checking
# interupting your command line usage, it’s much better to have something
# manually check the metadata once an hour (yum-updatesd will do this).
# metadata_expire=90m# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
As you can see, our local apt-cacher-ng VM is 10.1.1.12.
Run yum update and check your apt-cacher-ng’s cache – you should now see some CentOS respositories cached there.
This one is straight-forward for CentOS, Ubuntu and others distros:
id -u [username]
e.g.
id -u bob
That will give a numeric result like 500 or 1001.
To find out information about the CPU used in the system, we can use the following command:
lscpu
This gives us useful information about the CPU, such as the number of physical cores, virtual threads, virtualization support and more. An example output from a Haswell Xeon system looks like:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 60
Stepping: 3
CPU MHz: 800.000
BogoMIPS: 6784.21
Virtualisation: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
The above CPU is a Xeon E3-1245V3. The CPU speed reading as 800MHz is correct – this is the speed that Intel’s Speed Step technology drops the CPU down to to conserve power when the system is idle.
This command can be really useful when you’re using an unfamiliar system or a virtual machine where you’re not sure what hardware – or virtual hardware – lies beneath the OS.
To list the available hard drives (to be specific, available block devices) we use the following command:
lsblk
This will provide output in the following format:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
├─xvda1 202:1 0 7G 0 part /
├─xvda2 202:2 0 1K 0 part
└─xvda5 202:5 0 1022M 0 part [SWAP]
If you want to see the filesystems available on these block devices, we use the f flag:
sudo lsblk -f
If we don’t run this as root it won’t display the filesystems. The output looks like:
NAME FSTYPE LABEL MOUNTPOINT
xvda
├─xvda1 ext4 /
├─xvda2
└─xvda5 swap [SWAP]
There’s quite a bit of information in the above two outputs – we can see the block devices, their partitions, the mount points, the filesystems, their size and whether the partition is marked as readonly or not.
Sometimes you may want to check the output of dmesg from a previous session. This can provide some useful information – for example, whether an error has only just started appearing or whether it was present during previous sessions. Ubuntu archives old dmesg outputs in the following location:
/var/log
We can see how many are there with the following command:
ls -l /var/log/dmesg*
This should output a listing similar to this:
-rw-r—– 1 root adm 17169 Jan 10 17:07 dmesg
-rw-r—– 1 root adm 17170 Jan 9 20:28 dmesg.0
-rw-r—– 1 root adm 6063 Jan 9 20:22 dmesg.1.gz
-rw-r—– 1 root adm 6076 Jan 4 22:36 dmesg.2.gz
-rw-r—– 1 root adm 6108 Jan 4 22:27 dmesg.3.gz
-rw-r—– 1 root adm 6105 Jan 3 14:16 dmesg.4.gz
You can see that the old archives are compressed. To view the compressed files without decompressing them into the folder, we use the zless command. To do so with the first archive:
sudo zless /var/log/dmesg.1.gz
If you aren’t familiar with less you press ‘q’ to quit and return you to your prompt.
One thing you may have noticed when using the z switch with tar is that the compression can take some time! If you look at your CPU usage, though, you’ll notice that only one core is being utilised to compress the files. In a modern system 4 or 8 cores are common, meaning that there is plenty of potential to speed up the process if you could utilise more cores. As the gzip package only supports one core, we need to look elsewhere.
Fortunately, there is a gzip package which uses multiple cores available – it’s called pigz. To install it type:
sudo apt-get install pigz
Once that is installed we can tell the tar command to use it like so:
tar -c --use-compress-program=pigz -f [tar file] [directory or files]
e.g.:
tar -c --use-compress-program=pigz -f backupOfMovies.tar /opt/movies
Note the double hyphen before use. Check your CPU usage while the command is running – you should be able to see all available cores being utilised!
Sometimes you may with to add files to an existing backup; if you issue a command like:
tar -cvf /dev/st0 backupfiles
…and the tape is not already set to the end of the previous archive you will over-write any data from the position on the tape. Use the “eom” command to move the tape to the end of the alread-recorded files like so:
mt -f /dev/[path-to-tape] eom
e.g.:
mt -f /dev/st0 eom
Now you can use tar to add a file to the tape without over-writing the existing data.