Lenovo Z570 phy0 hard blocked solution

If you’ve had issues with wireless being grayed out and you’re unable to enable it on your Lenovo Z570 or any other box, there is a simple solution. You must reset your bios.

There’s an oddity in the bios for Lenovo Z570 machines; even after unblocking all interfaces, you can still see that phy0 is hard blocked, like below:


0: ideapad_wlan: Wireless LAN
Soft blocked: no
Hard blocked: no
1: ideapad_bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
3: hci0: Bluetooth
Soft blocked: no
Hard blocked: no

You may be seeing errors such as:


sudo ifconfig wlan0 up
SIOCSIFFLAGS: Operation not possible due to RF-kill

The solution is a reboot. Hit F2 to enter bios, then F9 to reset, then F10 to save and exit. Your wireless
should be working at that point.

This is a workaround for the bug located here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/782137

Apache Virtual Hosts with SNI and SSL on Ubuntu 12.04 in Rackspace

Here’s a little howto: I was having the devil of a time earlier today configuring an SSL cert for a site Lorraine and I are working on right now. My problem is that I’ve never configured an SSL cert before, and proceeded to jump right on in with a whole lot of enthusiasm and zero knowhow.

It turns out that because the site we’re working on is on a Rackspace cloud server, and we’re hosting several sites on the same server using Apache virtual hosts to configure http requests via hostname as opposed to IP address, there is some extra configuration to be done. Add to that the fact that we’re serving secure and insecure content at the same hostname, and you have a recipe for a headache. So, here’s the way I did it.

First, let me list the useful tutorials and links, and then I’ll post the config files and examples that worked.

The most useful: http://www.tc.umn.edu/~brams006/selfsign_ubuntu.html

http://en.wikipedia.org/wiki/Server_Name_Indication

http://en.gentoo-wiki.com/wiki/Apache2/SSL_and_Name_Based_Virtual_Hosts

http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

http://www.sslshopper.com/article-most-common-openssl-commands.html

Read this to understand why you’re doing this and what a certificate is: http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html

Pro tips:

  1. You don’t need to turn on the ”
    Listen 443″ switch in apache2.conf; that’s already on and enabled with mod_ssl, the Apache module that handles SSL.
  2. If you keep seeing people telling you to edit your ssl.conf, what they mean in Ubuntu is /etc/apache2/sites-available/default-ssl. There’s already the stub there.
  3. Generate a CSR easily and simply by pasting this into a bash shell: openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key
  4. You have to create a symbolic link between the default-ssl in sites-available and sites-enabled like this:
  5. sudo ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/000-default-ssl

Ok, now here’s the example default-ssl file:




ServerAdmin webmaster@localhost
DocumentRoot /path/to/your/website/root/
r

Options FollowSymLinks
AllowOverride None


Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all

ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn

CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined

Alias /doc/ "/usr/share/doc/"

Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128

SSLEngine on
SSLCertificateFile /path/to/cert
SSLCertificateKeyFile /path/to/key/generated/from/CSR
SSLCertificateChainFile /path/to/bundled/certs/
from/your/issuer


SSLOptions +StdEnvVars


SSLOptions +StdEnvVars

BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown



And here’s the trippy part: you actually don’t need to edit your current virtual host file (presuming you have it correctly configured to serve nonsecure content via port 80) which should be living in sites-available. I have the feeling that if I was trying to serve more than one secure site on this server that I’d need to configure a NameVirtualHost, but since I don’t, all requests on port 443 can just get shoved to the document root of the secured site. I’ll explore that later, I suppose.

How To Build A Ruby Server With RVM On Kubuntu 12.10

So I’m building a Ruby server right now for the first time. I’m going to list out here the resources I used as a skilled web dev to get this up and running right away. These links do assume that you know what you’re doing in the cloud, but if so, they’re the best way to get running fast.

http://guides.rubyonrails.org/getting_started.html
https://www.digitalocean.com/community/articles/how-to-install-ruby-on-rails-on-ubuntu-12-04-lts-precise-pangolin-with-rvm
This is the best link: http://www.andrehonsberg.com/article/install-rvm-ubuntu-1204-linux-for-ruby-193

And here are the steps:
n
Update, upgrade, dist-upgrade
ufw default deny and add 80 and ssh port
apt-get install build-essential git-core curl
bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer) echo '[[ -s "/home/andre/.rvm/scripts/rvm" ]] && source "/home/andre/.rvm/scripts/rvm"' >> ~/.bashrc
source ~/.bashrc
sudo apt-get install libsqlite3-dev
rvm pkg install zlib
rvm reinstall $(rvm list strings | tr "\n" ',')
rvm reinstall 1.9.3 --with-openssl-dir=/usr/local
rvm all-gemsets do rvm gemset pristine
gem install sqlite3-ruby -- --with-sqlite3-dir=/usr/local/lib
rvm gemset create rails31
rvm gemset use rails31
rvm current
gem list
echo "gem: --no-rdoc --no-ri" > ~/.gemrc
rvm pkg install openssl
sudo apt-get install -y libssl-dev
rvm reinstall $(rvm list strings | tr "\n" ',')
rvm all-gemsets do rvm gemset pristine
gem install rails
bundle install
rails new NewProject -d sqlite3
echo "gem '
therubyracer'" >> Gemfile

HOWTO: set up a cloud server with WordPress at Rackspace

You’re probably here because you are finally at the point where you need root access to your web server so that you can install applications like MediaWiki or WordPress or Joomla or any other CMS. If you have a website that you want to move away from a hosted environment, this is how to set yourself up so that you control every aspect of your site.

    1. Create an account at Rackspace.com. Go to Cloud Servers and create a new server. If you need help with this, though it’s very self-explanatory and easy on their site, you can always chat with their 24-7 online chat support. Note the administrative password and the IP address of the server you have created.
    2. Open a bash terminal and SSH into your shiny new server. “ssh root@YOURSERVERSIPADDRESS”. Enter the password.
    3. Create a user for yourself. “useradd -m -s /bin/bash yourname” and create a password for yourself  “passwd yourname”.
    4. Enter “su
      yourname”. Now, you are logged in under your name and not as root.
    5. Enter the following:
      sudo apt-get update
      sudo apt-get upgrade
      sudo apt-get install tasksel
      sudo tasksel install lamp-server
      sudo apt-get install php-mail python-software-properties unzip
      sudo a2enmod rewrite
      sudo apt-get autoclean
      sudo apt-get autoremove
      mkdir /home/yourname/yourwebsitename
      mkdir /home/yourname/yourwebsitename/blog
      cd /home/yourname/yourwebsitename/blogsudo
      wget http://wordpress.org/latest.tar.gz
      sudo tar -zxvf latest.tar.gz .
    6. That has cleaned up your server and installed a web server as well as WordPress. Enter passwords for your MySQL database and record them.
    7. “sudo service apache2 restart” #You will get an error that local server has not been set up.
      echo “ServerName localhost” | sudo tee /etc/apache2/conf.d/$servername
      sudo service apache2 restart #Should be no error now
    8. r

    9. cd /etc/apache2/sites-available/
      sudo nano yourwebsitename
    10. Copy this with CTRL+SHIFT+V into the terminal:
    11. ServerAdmin webmaster@localhost
      ServerName www.yourwebsitename.com
      ServerAlias yourwebsitename.com *.yourwebsitename.com
      DocumentRoot /home/yourname/yourwebsitename/
      php_value upload_max_filesize 1M

      Options +FollowSymLinks
      AllowOverride All
      Order allow,deny
      allow from all

      Options Indexes FollowSymLinks MultiViews
      AllowOverride All
      Order allow,deny
      allow from all

      ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

      AllowOverride None
      Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
      Order allow,deny
      Allow from all

      ErrorLog ${APACHE_LOG_DIR}/error.log

      # Possible values include: debug, info, notice, warn, error, crit,
      # alert, emerg.
      LogLevel warn

      CustomLog ${APACHE_LOG_DIR}/access.log combined

      Alias /doc/ “/usr/share/doc/”

      Options Indexes
      MultiViews FollowSymLinks
      AllowOverride None
      Order deny,allow
      Deny from all
      Allow from 127.0.0.0/255.0.0.0 ::1/128

       

       

    12. CTRL+X and save the file as yourwebsitename.com.
    13. cd /etc/apache2/sites-enabled/

sudo ln -s /etc/apache2/sites-available/yourwebsitename.com /etc/apache2/sites-enabled/yourwebsitename.com
sudo service apache2 restart

    1. Where have you created your domain name account? If it’s with GoDaddy, login to your GoDaddy account and click on Domain Manager. Click on the website name and enter the dashboard (or follow whatever practice your domain registrar uses to get to where you can edit the zone file). Click on “Edit Zone File”.
    2. Replace the IP address in the zone file with the IP address of your cloud server. Save the zone file.
    3. “nano /home/yourname/yourwebsitename/index.php” and copy this into the file.

/**
*
Front to the WordPress application. This file doesn't do anything, but loads
* wp-blog-header.php which does and tells WordPress to load the theme.
*
* @package WordPress
*//**
* Tells WordPress to load the WordPress theme and output it.
*
* @var bool
*/
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require(‘./blog/wp-blog-header.php’);
?>;

  • In a few minutes, you should be able to enter your URL into any browser, and see the WordPress installation page. Install using the database name and password you’ve created in PHPMyAdmin or in command line for MySQL.
  • I recommend Elegant Themes to get a beautiful and professional look for your site instantly.

 

HOWTO: Always know your home computer’s IP address from anywhere using Dropbox

To always know what your home machine’s IP address is (and while I’ll assume that you’re running Kubuntu, this can be adapted using the following bash script to any machine).

  • Apt-get ‘kcron’.
  • Open Task Scheduler and set the following bash script to run every five minutes:
#!/bin/bash
J=`wget http://checkip.dyndns.org/ -qO - | grep -Eo '\<[[:digit:]]{1,3}(\.[[:digit:]]{1,3}){3}\>'`
K=`date`
echo "$J $K" >> ../Dropbox/ANYDIRECTORYYOUCHOOSE/output.txt
  • Ensure the script is executable, and test it in a shell.

Now, you can always see what your home computer’s IP address is in any browser window; I use this in case there are issues with SSHing into my home box.

How to move WordPress sites between cloud servers using Ubuntu 11.10 and PHPMyAdmin

Here’s a quick howto:

I use Rackspace as my cloud service; I was moving a few sites from one server using Ubuntu 10.04 LTS (Lucid Lynx) to a new one using 11.10 (Oneiric Ocelot). I hit a few issues, so I thought I’d tell you how to export a WordPress site in its entirety and move it between two LAMP servers.

  1. Open a file manager on your local machine, and open both remote locations.
  2. Copy the root and all files of the site to your new server in the same location.
  3. Copy the sites-available virtual host file from /etc/apache2/sites-available/ directory to the same location on your new server.
  4. Create the symbolic link in sites-enabled by changing into /etc/apache2/sites-enabled/ and using this command: “sudo ln -s /etc/apache2/sites-available/yourhostfile yourhostfile”.
  5. Open PHPMyAdmin for your old server in a browser window. Login, and open the database for the site you want to move.
  6. Go to the Export tab. Assuming you’re using UTF-8 encoding (and that’s a very safe bet), all you have to do is ensure that the Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT box is checked under Structure, and that all options are highlighted in the Export box. Export the uncompressed database and save to a convenient location.
  7. Open PHPMyAdmin in your new server, login, and create a new database with the same name as the one you’re importing.
  8. Import the database you exported.
  9. Create a user on that database with the same name and password.
  10. Edit the DNS zone file for your site to point to the new IP address for your new server.
  11. SSH into your server, and use this command: “sudo service apache2 restart”.

Hit Ctrl+F5 once you think the DNS records will have propagated, and ensure it worked.

 

Dream gizmos

There’s a refrigerator that runs Linux now. That seems like a bit of overkill to me, but there are a few devices around the house that I think could use a bit of OSS ingenuity.

We have hibernation features for most laptops; is there a way to hibernate, say, a kitchen? Energy vampires like toasters (and I’m only going off of popular rumor, not fact here) are supposed to suck watts even when powered down. Wouldn’t it be handy to run a script that actually interfaces with your house’s power systems? I bet Bill Gates’ house does that already, so it’s time for the NIX crew to get it together 😉

My dream device: A kitchen touch screen computer like this one, but which can also be interfaced with remotely, and which can control the oven, the yogurt maker, the coffee
pot, and the dishwasher. With that, I’d be able to interface my OurGroceries list with the kitchen’s DB on food stores, cook something remotely that requires a long cooking period with changes in temperature over time (like a crown roast), preheat the oven as I’m getting home to throw a pizza in, and which can warn me if the freezer or refrigerator rise above a certain temperature (a sure sign that the cats have found a way to knock open a door).

How about you?

A response to “Nine Traits of a Veteran Unix Admin”

Paul Venezia over at InfoWorld sent me a valentine last week in the form of his entertaining blog post Nine Traits of the Veteran Unix Admin. His post is witty and rings of truth, but the points of conflict we have are places where I tend to think that Venezia has a strong opinion and anecdotal experience instead of any real metric for success in identifying a *nix vet.

Veteran Unix admin trait No. 1: We don’t use sudo

Venezia has a point. If you don’t know what you’re doing, you shouldn’t be in /etc/sudoers anyway.

Veteran Unix admin trait No. 2: We use vi, not emacs, and definitely not pico or nano

Here’s where a personal opinion jumps on into Venezia’s argument. I happen to be a KDE fan, and as a result, I tried out Kate several years ago. I am a HUGE fan. Kate is slim, has tabbed file access, syntax highlighting, and just barely enough features to be functional and tiny. I write almost all my code in Kate now. I think the real question Venezia should be addressing is whether a *nix vet uses an IDE or writes their code hardcore. I can and do write scripts or styles or for-loops on a beer-stained cocktail napkin; why on earth would it matter what interface I use to get my code into a compiler?

Veteran Unix admin trait No. 3: We wield regular expressions like weapons

My favorite use of regex is to identify files where two words appear within a certain character distance of each other. I have a very associative memory, and if I am looking for a file in the depths of my memory as well as a hard drive, I will often use
the proximity of two words as the key in the KV pair of my mind DB. I do agree that regex works like a charm, but specializing in it can be just as isolating as Venezia suggests.

Veteran Unix admin trait No. 4: We’re inherently lazy

He’s dead on the money. Venezia’s claim that we will take days or weeks to solve a problem in order to never have to deal with it again is blindingly accurate. However, I think he hasn’t gone quite far enough. ‘Lazy’ is a good word for it, but ‘insatiably curious to the point of distraction’ would be a better way to put it. I tend to think that solving a problem is a two-pronged process; writing the bash script is the second part. The first step is LEARNING what you didn’t know before. I wrote scripts to divide text files with very specific logic, but writing the script in the end only took a minute. It was learning what I needed to do and debugging, as well as committing the process to memory, that took five days.

nVeteran Unix admin trait No. 5: We prefer elegant solutions

Quod Erat Demonstrandum

Veteran Unix admin trait No. 6: We generally assume the problem is with whomever is asking the question

“Many think that this is a sign of hubris or arrogance. It definitely is — but we’ve earned it.”

Venezia is right in what he says above, but again, he hasn’t gone quite deep enough. We DO assume that the problem is with the person asking the question, because barring hardware failure, computers do not err. That means that if something isn’t working and we can’t figure out why, we believe the problem lies with us and our lack of knowledge or experience in solving that problem. The right to believe that the problem lies with the person asking the question does NOT come with the right to belittle that person, or 97% of the time, we’d be self-immolating over our keyboards. Instead, this statement is a comprehensive acceptance of
responsibility for learning the answers ourselves, and helping n00bs in the same way we ourselves were helped on the Yellow Brick Road to *nix guru-hood.

Veteran Unix admin trait No. 7: We have more in common with medical examiners than doctors

No. We have more in common with medical researchers than doctors. We want to know why things work, and to come up with new solutions no one has ever seen before. We do need to know the whyfors of the problems we’ve already solved, and there are very few things that irritate me more than making a code change that resolves a bug…but not knowing WHY it fixed the problem. I will spend days trying to learn why my code change worked, and barring direct instructions to do so, I will not put that code into production, because if I don’t know why a code change worked, I cannot guarantee that there will not be secondary issues that arise from my use of code I don’t fully understand. sudo rm -R /home/tarahmarie/.kde may
fix my SQLITE problem with Amarok, but it creates more problems than it solves, to say the least.

Veteran Unix admin trait No. 8: We know more about Windows than we’ll ever let on

Slight disagreement here. I have no problem knowing Windows. Getting inside the guts of a Windows box is harder than a nix box, but there are a few tools that absolutely rule on Windows. Absolutely number one is PowerShell. PowerShell is completely integrated with the .NET architecture, and you can instantiate classes directly from the command line without wrapping them in a script. This is one powerful hammer in the toolbox. You can actually pipe fully instantiated objects rather than passing a character stream that’s then interpreted, as you would in bash. Regardless of that, I want to use the best tool for the job. Call it ‘OS zen’ or whatever you like; I’d rather just get the job done, and that may involve me learning more
PowerShell rather than trying to change the institutional inertia that causes no other option than Windows to be considered.

Veteran Unix admin trait No. 9: Rebooting is almost never an option

sudo service apache2 restart

Who needs to reboot?

wget -i http://www.rottentomatoes.com/m/10011582-TRON_legacy/

tarahmarie@tarahmarie-netbook-ubuntu:~$ whoami
tarahmarie
tarahmarie@tarahmarie-netbook-ubuntu:~$ tron -v
legacy
tarahmarie@tarahmarie-netbook-ubuntu:~$ yum cillian-murphy
yum cillian-murphy: Permission denied.
tarahmarie@tarahmarie-netbook-ubuntu:~$ sudo yum cillian-murphy
You wish.
tarahmarie@tarahmarie-netbook-ubuntu:~$ sudo apt-get install imax
Hardware upgrade required. Take out a mortgage.
tarahmarie@tarahmarie-netbook-ubuntu:~$ runonce | imax -3d tron-legacy
If I have to, but I’m only tainting one of my cores with this fluff.
tarahmarie@tarahmarie-netbook-ubuntu:~$ exit
Thank you, God.

Rackspace Encomium

There is nothing like configuring your own server to start getting a real understanding of how the guts of LAMP works. I’ve configured a lot of servers, but never built an entire Apache server from scratch before. Rackspace offers a cloud server for as little as $10 a month.

One of the first things you’ll want to do is create a server instance. I chose Ubuntu Maverick Meerkat (somewhat reflexively) as a server image. Rackspace builds the image and sends you an email when it’s done. You’ll use those credentials to login…but what next?

Though you can use the JavaScript console at Rackspace, the best move is to install SSH and create a user with sudoing privileges. This is where I started to get into areas that I wasn’t familiar with. I hadn’t configured SSH before, and Ubuntu creates users with the relevant permissions on graphical installation.

I would start giving instructions, but the truth is that I learned the most by
tracking down the instructions myself. So, I’ll instead give a list of the things you’ll need to do.

  1. Install and configure SSH. Alter the standard port from 22 to something else so you don’t get hit by bots.
  2. Add a user with a home directory.
  3. Add that user to sudoers.
  4. Log out from the Rackspace console.
  5. Use either a bash shell from a NIX box or download Putty for use from a Windows machine.
  6. Krusader or Dolphin will work fine for file transport from NIX; download WinSCP for SFTP (secure file transfer protocol).
  7. Login using your shell and your new user. Use nano as a text editor for your work; it’s simplest. Install LAMP, Open SSL, and any other packages you want…but LAMP will do it. Use Tasksel–it’s the simplest way to install the full server.
  8. Use one of your spare domain names or a subdomain (blank.yourdomain.com), and point it to the IP address of your shiny new server.
  9. Configure
    your Apache Virtual Hosts (use sites-available and sites-enabled) to catch the incoming requests. That means to point requests for blank.yourdomain.com to a directory on your server, typically /var/www, but you can choose any. I’ve got sites in my home directory under individual names.
  10. Transfer files for any site using your SFTP or SCP protocols.
  11. Try hitting the site.

It’s rather simple, but it will take a while to configure. It’s fun to learn, but will be complicated, and is best treated as a hobby until you’ve got the security down. I’m also happy to answer questions.