Working Ninja
2016-11-01T16:55:19

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.

2016-03-31T22:34:52

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.

2016-03-26T10:26:48

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

2016-03-10T17:26:15
$ 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

2016-02-04T07:37:49

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

2016-01-21T22:03:11

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

2016-01-17T12:54:16

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

2016-01-17T12:08:12

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.

2016-01-03T18:09:00

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

2015-12-30T20:50:04
if [ "$TERM" = "linux" ]; then
    echo -en "\e]P0232323" #black
    echo -en "\e]P82B2B2B" #darkgrey
    echo -en "\e]P1D75F5F" #darkred
    echo -en "\e]P9E33636" #red
    echo -en "\e]P287AF5F" #darkgreen
    echo -en "\e]PA98E34D" #green
    echo -en "\e]P3D7AF87" #brown
    echo -en "\e]PBFFD75F" #yellow
    echo -en "\e]P48787AF" #darkblue
    echo -en "\e]PC7373C9" #blue
    echo -en "\e]P5BD53A5" #darkmagenta
    echo -en "\e]PDD633B2" #magenta
    echo -en "\e]P65FAFAF" #darkcyan
    echo -en "\e]PE44C9C9" #cyan
    echo -en "\e]P7E5E5E5" #lightgrey
    echo -en "\e]PFFFFFFF" #white
    clear #for background artifacting
fi

Source: https://askubuntu.com/questions/147462/how-can-i-change-the-tty-colors#153493