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!
Running nginx (or lighttpd, or any other web server) but still want to make use of Apache’s useful ab (apachebench) benchmarking tool?
apt-get install apache2-utils
…should do it.
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.
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!
Following on from the article on writing files to a tape backup, what happens if you want to back up more than what fits on a single tape? Here we want to use the –multi-volume switch, or -M. Use it so:
tar -cvMf /dev/[path-to-tape] [backup folder or files]
As a working example:
tar -cvMf /dev/st0 /opt/movies
Once the first tape is full, tar will prompt you to insert another:
Prepare volume #2 for `/dev/st0′ and hit return:
Make sure you replace the tape with another before hitting return or else it will over-write the just-finished tape!
With the exception of a file which sits across multiple tapes (think of a file which starts at the end of one tapes and finishes at the start of the next) you don’t need a first tape to restore the files on the second. You also cannot use compression for multi-volume archives.
A customer upgraded from 13.04 to 13.10 and their internal wiki was broken afterwards; for a simple Apache install where the wiki was installed at the web root and all access was via the LAN (thus they were happy with not restricting the access), the fix was to add:
<Location />
Require all granted
</Location>
towards the bottom of:
/etc/apache2/sites-enabled/000-default.conf
…just above the last line, which should be </VirtualHost>.
Restart apache with:
service apache2 restart
After that you should be able to refresh and see your wiki as before.