apt-add-repository: command not found on Ubuntu

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!

How to protect Ubuntu against the Shellshock exploit

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-upgrade bash
  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.

new free dating apps

  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:  
  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= #  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   Run yum update and check your apt-cacher-ng’s cache – you should now see some CentOS respositories cached there.

Ubuntu: How to see information about your system’s CPU

  To find out information about the CPU used in the system, we can use the following command:  
  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.

Ubuntu: Viewing all available block devices or hard drives, their mount point and their filesystems

  To list the available hard drives (to be specific, available block devices) we use the following command:  
  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.  

Ubuntu: Viewing past dmesg outputs from previous sessions

  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:  
  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.  

Ubuntu: How to use multiple cores with tar gzip compression

  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]
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!

Ubuntu: Using tar to span a backup across multiple tapes

  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.

Mediawiki 403 forbidden errors after upgrading to Ubuntu 13.10

  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:  
…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.