Server
Install NFS server components:

# apt-get install nfs-kernel-server portmap

Add the "root" of all shares (if this is your only share, this should be all you need):

# echo "/home 192.168.1.0/24(ro,fsid=0)" >> /etc/exports

Add additional shares:

# echo "/home/joe 192.168.1.0/24(rw,sync,no_subtree_check)" >> /etc/exports

Update NFS exports table:

# exportfs -avr

Restart NFS server:

# service nfs-kernel-server restart

Don't forget to allow NFS through iptables.

Client

# apt-get install nfs-common
# mount server:/share /share

Prosit!

Notes

Slow initial directory listing is caused by aliases (specifically color output). Explanation here: http://www.novell.com/support/kb/doc.php?id=7005969. Use \ls -la instead of ll as a workaround.

Sources:
https://wiki.debian.org/NFS
https://help.ubuntu.com/community/SettingUpNFSHowTo
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-server-config-exports.html
http://www.tldp.org/HOWTO/NFS-HOWTO/intro.html
http://nfs.sourceforge.net/nfs-howto/ar01s07.html

Before adding a script to cron and finding that it doesn't work because of a PATH issue, here's a handy command to test:

env -i ./script

This will run your script in the same environment that cron will.

I must have it saved somewhere but it was nowhere to be found. The password was lost. My root account was forever secure--or was it?

# service mariadb stop
# mysqld_safe --skip-grant-tables &
# mysql -u root
> USE mysql
> UPDATE user SET password=PASSWORD("mynewpassword") WHERE User='root';
> FLUSH PRIVILEGES
> QUIT

This didn't stop the mysqld_safe process, so I killed the parent mysql process (/usr/libexec/mysqld) via its process ID ($pid).

# kill $pid

Start MySQL back up.

# service mariadb start

Finally, for security purposes, remove the UPDATE user ... SQL statement from ~/.mysql_history.

Profit! And don't forget to securely store your password.

GitLab was throwing me a 500 server error this morning after an upgrade via yum. To troubleshoot, I ran the self diagnose command from terminal:

# gitlab-rake gitlab:check

Which gave me the following error to fix:

All migrations up? ... no
  Try fixing it:
  sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
  Please fix the error above and rerun the checks.

Since I installed GitLab via a yum package, I ran a slightly different command to run the GitLab migrations:

# gitlab-rake db:migrate RAILS_ENV=production

Now I was presented with the source of the issue, relating to PostgreSQL. I needed to enable the pg_trgm extension:

== 20160226114608 AddTrigramIndexesForSearching: migrating ====================
-- execute("SELECT true AS enabled FROM pg_available_extensions WHERE name = 'pg_trgm' AND installed_version IS NOT NULL;")
   -> 0.0066s
rake aborted!
StandardError: An error has occurred, all later migrations canceled:

You must enable the pg_trgm extension. You can do so by running "CREATE EXTENSION pg_trgm;" as a PostgreSQL super user, this must be done for every GitLab database.

And sure enough, others were having the same issue. These are the steps they (and I) executed to fix the issue:

# yum install postgresql-contrib
# su - postgres
$ psql -d gitlabhq_production -c "CREATE EXTENSION pg_trgm;"
$ exit
# gitlab-rake db:migrate RAILS_ENV=production
# gitlab-ctl reconfigure
# gitlab-ctl restart

Profit!

Source: https://gitlab.com/gitlab-org/gitlab-ce/issues/14526

$ VBoxManage modifyhd YOUR_HARD_DISK.vdi --resize SIZE_IN_MB

Source: http://askubuntu.com/questions/88647/how-do-i-increase-the-hard-disk-size-of-the-virtual-machine

I went to update my Ubuntu machine today and found out there wasn't enough space on /boot to perform the update. You can remove older kernels to free up space:

// Check which kernel you're using
$ uname -r

// List all installed kernels
# dpkg --list 'linux-image*'

// Remove the kernel (I recommend the oldest [kernel with the smallest number])
# apt-get remove linux-image-VERSION

Source: https://askubuntu.com/questions/345588/what-is-the-safest-way-to-clean-up-boot-partition

Unable to boot after kernel (3.19) upgrade on Ubuntu. Here's the fix:

1. Add copy_modules_dir kernel/ubuntu/i915 to /usr/share/initramfs-tools/hooks/framebuffer.
2. Then run update-initramfs -k all -u.
3. Profit.

Fix found here: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1500751

Error:

The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.

Solution:

# dd if=/dev/zero of=/dev/sdb bs=2048

Source: http://askubuntu.com/questions/675649/unable-to-delete-usb-drive-partitions-block-size-error

Use dmesg after plugging in your USB thumb drive to find the device name (/dev/sdb).

# umount /media/username/devicename
# dd bs=4M if=/path/to/filename.iso of=/dev/sdb

Note, do not output to a partition (e.g. /dev/sdb1). In the past this has created a loop device instead of copying the input file to the USB thumb drive.

lsusb shows us that—sure enough—Apple's IR receiver is being loaded on boot:

# lsusb
Bus 005 Device 002: ID 05ac:8242 Apple, Inc. Built-in IR Receiver

lsmod reveals hid_appleir is the module being loading for our remote. Let's blacklist it:

# echo 'blacklist hid_appleir' > /etc/modprobe.d/hid_appleir.conf
# depmod -ae
# update-initramfs -u
# reboot now

That should take care of it!

More helpful tips and explanation here: https://wiki.debian.org/KernelModuleBlacklisting