Fedora 20 - Missing WIFI driver/support on clean install

I've started a little experiment on porting a crashed windows 7 Laptop (Dell Inspiron 1525) over to Linux. Why Linux at this point? The crash was largely due to the infamous Windows Update Issue. For me that was the straw that broke the camel's back.

The experiment part of this update comes from the fact that the user has never really used Linux before, so this is really a true test of the user-friendliness of the OS, once initially set up. My weapon of choice was Fedora 20, largely because I'm entrenched in the RHEL distribution tree for almost everything that I do, so it's naturally easier for me to troubleshoot quickly.

The installation and initial configuration went pretty smoothly, except for the fact that out of the box, WIFI appeared nonexistent. This was not a big problem, as it worked on a Kali Linux Live USB, so I knew that the hardware was fine. From the old install I knew that the device was Broadcom based, so I had a launch point.

Credit to http://wireless.kernel.org/en/users/Drivers/b43 for thoroughly documenting the resolution of this issue.

First check the device for support:
0. As root:
lspci -vnn -d 14e4:

It spat out some device information, including the model, in my case the Broadcom Corporation BCM4312, which was supported by the b43 driver. I compared the output to the corresponding CHIP ID segment on the table
Taken from: http://wireless.kernel.org/en/users/Drivers/b43

PCI-ID	Supported?	Chip ID	Modes	PHY version	Alternative
14e4:4315	yes	BCM4312	b/g	LP (r1)	wl

The Fedora specific instructions are as follows:
1. Install the firmware extractor tool

su -

yum install b43-fwcutter wget

2. Install the driver

Define the Firmware path (Fedora specific)

export FIRMWARE_INSTALL_DIR="/lib/firmware"
Download and extract the Broadcom driver

wget http://mirror2.openwrt.org/sources/broadcom-wl-5.10.56.27.3_mipsel.tar.bz2

tar xjf broadcom-wl-5.10.56.27.3_mipsel.tar.bz2

Install the driver

sudo b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" broadcom-wl-5.10.56.27.3/driver/wl_apsta/wl_prebuilt.o

3. Reboot

These steps were sufficient for me, as soon as I rebooted the WIFI was available to connect. If these steps do not solve your issue, you may need to blacklist older drivers. Take a read here: http://wireless.kernel.org/en/users/Drivers/b43

Maybe I'll break the chains of Microsoft bondage on my own laptop - which oddly enough, works swimmingly on a fresh Windows 8.1 installation. We'll see.

-noveck

Introduction to Linux Systems Administration (a Workshop)

I recently delivered a free 5 (half) day workshop on an Introduction to Linux Systems Administration. The information was culled from a range of web sources, classes and personal notes, so all credit to the respective sources. All practicals were tested on a vanilla CentOS 6.5 Virtual Machine on VMWare Player, which is free for personal use.

At the end of the workshop, I asked the participants to describe what they thought of Linux using one or two words, and this was the result:

I'd like to share the PDF version of the presentation and if you have any feedback, drop me a line. It's very much a work in progress and I welcome your contributions!

-Noveck

Migrating a Virtual Machine from VMWare Player to ESXi

This post covers the migration of a virtual machine from a VMWare Player environment, which is located on my workstation (Windows 7 64-bit), to a VMWare ESXi server in my datacenter.

Both are the free versions, so they don't have all the fancy bells and whistles as the awesome licensed versions.

It took a bit of doing, but it's relatively straightforward.


1. Upgrade VMWare player (if necessary)
I realized that I was using version 3.0, and was a 'few' versions behind. Newer versions contain the OVFTool, which we will use to create the ESXi ready OVF.
Visit here: http://www.vmware.com/products/player


2. Upgrade and Reboot your pitiful workstation.

3. Read the VMWare OVFTool guide. Or not.

4. Login to the Virtual Machine in VMWare Player and uninstall the VMWare Tools. Reboot VM.

5. When VM boots, ignore any driver errors. Do a clean shutdown.

6. Export the OVF from the VM
Open Command Prompt as Administrator
cd C:\Program Files\VMWare\VMWare OVF Tool

Make sure the tool works, run the help
ovftool -h

You should be presented with a range of flag options.

Export the OVF
ovftool "C:\Path to VMname.vmx" "C:\Path to place OVF"
If the output does not look like this, it might be a good idea to check the documentation.

7. Import the OVF Into VMWare ESXi
Login to your ESXi Host
Click File -> Deploy OVF Template
Browse to "C:\Path to place OVF" as specified in step 6.
Use defaults, or configure accordingly.
When completed boot VM in ESXi, enable the network adapter and update the IP/Hostname or any other relevant configuration.

That's it!

Issues with Percona Xtrabackup on CentOS 5/MySQL 5.0

I've got a couple servers that really can't move from CentOS5 / MySQL 5.0 just yet, and while attempting to restore a MySQL InnoDB database backup using percona's innobackupex/xtrabackup, I got the following error (hashtags added, 'cause I can't remember the exact preamble.):


Can't exec "xtrabackup_51": No such file or directory at /usr/local/bin/innobackupex-############

#### fatal error: no 'mysqld' group in MySQL options
 
Absolutely freaking beautiful.

 Turns out that it's caused due to the automatic yum update to  version 2.1.x of the xtrabackup application, which uses the MySQL 5.1+ plugins and fortunately, it's a very quick fix, even though I nearly pulled out what little hair I have to figure it out. Thankfully percona includes the last version with their repo, so it's just to specify the version and it's gonna work again.


0. Got root/sudo

1. Remove existing xtrabackup package.  
yum remove xtrabackup

2. Check that the older version of the package is available from the repo 
yum list | grep percona


3. Specify/Install version 2.0 explicitly (choose based on your OS version!)
yum install percona-xtrabackup-20.x86_64


It's as simple as that! No need to pull out your hair just yet or try to build from source, which is it's own piece of work thanks to cryptic documentation.

To avoid this from happening again, I'd suggest disabling the percona repo when doing a yum update for the entire server, or manually patching the version by calling yum update percona-xtrabackup-20.

Cheerio
-noveck

SSL Secured Apache Webserver

Here's a quick way to run an SSL Secured Webserver. Ideally, a trusted Certificate Authority should be used, but as a proof of concept, we'll be generating our own self-signed certificate.

This assumes a fully functional Apache Webserver running on CentOS Linux.

0. Login as root/sudo into the terminal

1. Install prerequisites
yum install mod_ssl openssl

2. Generate Certificate / Private Key
(or use instructions from trusted CA with a purchased certificate) 
openssl genrsa -out ca.key 1024

3. Generate Certificate Signing Request (CSR)
openssl req -new -key ca.key -out ca.csr

4. Generate Self Signed Key
openssl -x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

5. Copy files to appropriate locations
cp ca.crt /etc/pki/tls/certs
cp ca.key /etc/pki/tls/private/ca.key
cp ca.csr /etc/pki/tls/private/ca.csr

6. For SELinux
restorecon -Rvf /etc/pki

7. Update the Apache SSL config file
vi +/SSLCertificateFile /etc/httpd/conf.d/ssl.conf

Edit the two entries in the file

SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key

8. Restart Apache
service httpd restart


9. Configure the firewall to accept incoming SSL requests
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
service iptables save
iptables -L –v


10. Test
From a web browser hit https://servername.com and the page should be displayed.


Finito!
Now get some coffee.:)

-noveck

Troubleshooting VNC Connection error

So I'm back out to work after a nice vacation, so I should have seen this coming, right?

When attempting to connect to my VNC Server from my client, a nice error message popped up.
Unable to connect to server.
I managed to ssh into the server, but the VNC Server refused to restart:

[myuser@xxxxxx tmp]# service vncserver restart
Shutting down VNC server: 3:myuser                         [FAILED]
Starting VNC server: 3:myuser
Warning: xxx.xxx.xxx:3 is taken because of /tmp/.X3-lock
Remove this file if there is no X server xxx.xxx.xxx.xxx:3
A VNC server is already running as :3                         [FAILED]







Long story short, I had to delete the lockfile and socket in order to be able restart the VNC Server.

0. Login as root/sudo
1. Remove lock file and socket
rm -rf /tmp/.X3-lock
rm -rf /tmp/.X11-unix/X3

2. Restart vnc service
service vncserver restart

Standalone server reporting with Sar and KSar

Zabbix is a great tool for monitoring and reporting for multiple servers and that installation is covered here. In this instance, Sar and KSar will be used as a standalone data collection tool, as it falls outside the physical and networking reach of my Zabbix server.


Sar is a neat little tool that is part of the sysstat package, more information can be found on the author's website. In my case, we will be using to collect data on CPU, Memory, Swap, Network and all the other metrics that can make or break a Linux based service.

kSar is a separate java based tool that generates some lovely graphs using the collected sar data, because a picture paints a thousand words, or in this case, a graph summarizes a crapload of data.

This tutorial covers the installation of both, as well as a practical usage scenario.

0. Got root/ sudo?



1. Install the packagesyum install sysstat java



2. Set the sysstat cron to run
nano /etc/cron.d/sysstat
Ensure the following lines are active / not commented out. The first line specifies how often the tool should take a snapshot, the second is when the daily summary is processed.


*/10 * * * * root /usr/lib/sa/sa1 1 1
53 23 * * * root /usr/lib/sa/sa2 –A

3. Configure sar to keep a month's worth of data
By default, sar keeps 7 days worth of data. Since we need data monthly, the configuration needs updating.

nano /etc/sysconfig/sysstat

Update line, HISTORY = 7 to now read:
HISTORY = 31

4. Download kSar
Located at http://sourceforge.net/projects/ksar
Create a folder to store kSar and Monthly text files
mkdir /mon
Extract kSar into /mon
Change permissions to make kSar executable
chmod +x /mon/kSar


5. View Daily Server Data (default)
Prep report:
LC_ALL=C sar -A > /mon/sardata.txt

See the graphs
cd /mon/kSarx.x.x/
./run.sh

Click "Data" Menu option -> Load from text file
Select /mon/sardata.txt

6. View Monthly Server Data (see below for actual script)

Prep report:
cd /mon/
./sarprep_monthly.sh
(Ensure script is executable before running!)

See the graphs
cd /mon/kSarx.x.x/
./run.sh

Click "Data" Menu option -> Load from text file
Select /mon/sarmonthly_July.txt (use appropriate month name)

7. All done!

sarprep_monthly.sh
#cleanup old monthly file
rm -rf /mon/sarmonthly_$(date +"%B").txt
#loop through 31 possible days, merge all files into one
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31; do
LC_ALL=C sar -A -f /var/log/sa/sa$i >> /mon/sarmonthly_$(date + "%B").txt
done


That's it! Til next time...
-noveck