Create Networks

In this section, I list the steps to create two OpenStack networks:

1. Homelan. This network connects the OpenStack VMs to an external network, which in my case is my home LAN.
2. Tenant.  This network connects the OpenStack VMs internally.

From the root login,  run the following neutron commands:

Create network homelan-net, subnet homelan-subnet

My OpenStack Kilo server sits in my home network, 192.168.100.0/26.  The server is .154 and gateway .162.  The homelan-net network gateways to my home LAN and through my cable modem, to the internet.   The virtual machines that sit inside the OpenStack cloud on a different network and will map their IP addresses to one of the IP addresses in the allocation pool .70 thru .99.  This mapping is assigned one at a time as the VMs are created.

# source keystonerc_admin
# neutron net-create homelan-net --router:external
# neutron subnet-create homelan-net 192.168.100.0/24 \
   --name homelan-subnet \
   --allocation-pool start=192.168.100.70,end=192.168.100.99 \
   --disable-dhcp --gateway 192.168.100.162

Create network tenant-net, subnet tenant-subnet

The neutron commands below create a tentant-net that has a DHCP-based address pool  in the 10.0.0.0/24 address block.  Virtual machines will be created  with an address from this DHCP address pool.

# neutron net-create tenant-net
# neutron subnet-create tenant-net 10.0.0.0/24 \
    --name tenant-subnet --gateway 10.0.0.1 --dns-nameservers list=true\          8.8.4.4 8.8.8.8

Verify the setup by going to the OpenStack  dashboard. It displays the networks:

Admin->Networks

Create Router

After creating the networks, connect them together through a router, using the following neutron commands:

# neutron router-create router1
# neutron router-interface-add router1 tenant-subnet
# neutron router-gateway-set router1 homelan-net

The router setup can be verified at the OpenStack dashboard:

Admin->Routers

Admin->Routers->router1

The OpenStack Dashboard displays the same thing, but graphically.

The tenant-net is where the instances will connect.  Let’s bring up two.

Spin-up Cirros Instance

WIth the networks and router setup, we have the base for spinning up the default image supplied with the packstack installation.

Cirros is a barebones linux distribution well-suited for verifying OpenStack installations.

You can see the cirros image in the OpenStack dashboard:

To spin-up cirros, first setup a key-pair and some access control rules:

# nova keypair-add 080315-key > 080315-key.key
# chmod 600 080315-key.key
# nova keypair-list
+------------+-------------------------------------------------+
| Name       | Fingerprint                                     |
+------------+-------------------------------------------------+
| 080315-key | c9:02:a4:18:f5:32:f4:3c:64:5a:0e:e1:5e:be:f8:39 |
+------------+-------------------------------------------------+
# nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
# nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
# nova secgroup-add-rule default tcp 80 80  0.0.0.0/0

Now use the nova command to boot-up a cirros instance.  The nova command needs to know the id of the tenant-net.  I can get this with the neutron net-list command.

# neutron net-list
+--------------------------------------+-------------+-------------------------------------------------------+
| id                                   | name        | subnets                                               |
+--------------------------------------+-------------+-------------------------------------------------------+
| f8f04abf-dcba-46b7-9094-910e58530f0f | tenant-net  | 4a626740-7a14-443a-873d-d490132bbe10 10.0.0.0/24      |
| dbc40c3e-0175-4774-8b63-20896990c806 | homelan-net | 81f1eb33-0265-4d23-b668-d69b7a29c4b1 192.168.100.0/24 |
+--------------------------------------+-------------+-------------------------------------------------------+

# nova boot --flavor m1.tiny --image cirros 
       --nic net-id=f8f04abf-dcba-46b7-9094-910e58530f0f   
       --security-group default --key-name 080315-key cirros081315
#

The new image, named  cirros081315, interfaces to the tenant-net network; it is allocated a DHCP-based address from the 10.0.0.0/24 pool.  The virtual machine needs to have it’s IP address mapped through the router to a floating IP address on  the homelan interface of the router.

The following commands allocates a floating IP address,  then the IP address gets associated with the cirros instance.

# neutron floatingip-create homelan-net
Created a new floatingip:
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| fixed_ip_address    |                                      |
| floating_ip_address | 192.168.100.71                       |
| floating_network_id | dbc40c3e-0175-4774-8b63-20896990c806 |
| id                  | f104ccad-7227-4bc8-8bc5-e74a9656cfd5 |
| port_id             |                                      |
| router_id           |                                      |
| status              | DOWN                                 |
| tenant_id           | 0487893a0cdb4ac18c8837f9e7e177ab     |
+---------------------+--------------------------------------+
# nova floating-ip-associate cirros081315 192.168.100.71

The new instance can be found in the OpenStack dashboard:

Login to the instance using the following:

ssh -i 080315-key.key cirros@192.168.100.71

Verify that  pings to  the internet work, verify ssh to other servers on the homelan. If you get this far, things are in pretty good shape.

Spin-up a Fedora instance

With cirros working, I want to verify that I can import my usual image and spin it up.    And, I haven’t used Fedora 22 yet and this will give me a chance to see what’s changed.

The following commands imports a Fedora image, spins it up into instance, then using a floating IP address, maps the instance to my home LAN.

# glance image-list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 571a3d1f-afce-4e8b-b180-acf11903ada2 | cirros                 |
| e6c70bd3-dd5c-4687-ba5f-2bf6c6196b22 | Fedora 22 Cloud x86_64 |
+--------------------------------------+------------------------+

# nova boot --flavor m1.small --image "Fedora 22 Cloud x86_64" \
  --nic net-id=f8f04abf-dcba-46b7-9094-910e58530f0f \  
  --security-group default \
  --key-name 080315-key fedora22080315
# neutron floatingip-create homelan-net
Created a new floatingip:
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| fixed_ip_address    |                                      |
| floating_ip_address | 192.168.100.72                       |
| floating_network_id | dbc40c3e-0175-4774-8b63-20896990c806 |
| id                  | d23783fe-18bc-44b8-9ba6-299c7917046c |
| port_id             |                                      |
| router_id           |                                      |
| status              | DOWN                                 |
| tenant_id           | 0487893a0cdb4ac18c8837f9e7e177ab     |
+---------------------+--------------------------------------+
# nova floating-ip-associate fedora22080315  192.168.100.72

Note that this new Fedora instance uses the same key-name and net-id as the cirros instance.  Login to the instance and verify connectivity:

# ssh -i 080315-key.key fedora@192.168.100.72
The authenticity of host '192.168.100.72 (192.168.100.72)' can't be established.
ECDSA key fingerprint is 1a:60:ef:e1:9b:f1:78:72:61:47:01:54:ab:21:6e:5d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.100.72' (ECDSA) to the list of known hosts.
$ ping yahoo.com
PING yahoo.com (206.190.36.45) 56(84) bytes of data.
64 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=1 ttl=47 time=107 ms
64 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=2 ttl=47 time=135 ms
64 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=3 ttl=47 time=120 ms
^C

The OpenStack dashboard screen caps below show the Fedora and Cirros instances:

Project->Instances

Projects->Network->Network Topology

Web Server on Fedora 22

Just to confirm end-to-end networking, the following steps setup a web server on the Fedora 22 instance.  Continuing from the Fedora ssh session above, run the following:

$ sudo su -
# yum groupinstall "Web Server"
# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
# systemctl start  httpd.service

The IP address for the Fedora instance is .72.  Go to another PC on the homelan and verify that the newly installed web server works. The default apache test page looks like the following:

Comments

In my write-up here, I setup the networks, router, image, and instances using OpenStack command lines.  In past installations, I used the OpenStack dashboard.  This time around I took the extra effort to learn the command lines.   I would say that the web interface was easier and probably what I will use going forward.

For my records, and the potential benefit of others, here’s the entire sequence of commands all in one big gist:

References

• Diving into OpenStack Network Architecture – Part 2 – Basic Use Cases
• Create initial networks
• Launch an instance with OpenStack Networking (neutron)
• Deploying OpenStack KILO Using RDO
• RDO Quickstart: Doing the Neutron Dance

The post Openstack Kilo on home network – part 2 appeared first on JackKozik.com.

I generally followed the RDO Quickstart instructions, so chapeau to the community for laying out the steps for me.

CENTOS7 with Static IP.

I picked CENTOS7 and did a bare-metal install usinga DVD I burned from the iso image named CentOS-7-x86_64-LiveKDE-1503.  I installed new disk partitions, reformatting my drives.

As I learned from previous packstack installs, the networking needs to be configured with a static IP address. This can be done at CENTOS7 install time.  Look for the “Networking & Hosts” button. Click it. On the next screen, there will be an icon at the bottom right; click it and edit the interface: change it from DHCP to manual.

The following screen cap from CENTOS7 install gives  an idea of what I did.

My passed Fedora/Centos install experience is to let the default DHCP networking  get installed, then manually change things to static IP address. Not this time; here, I found setting the static IP at install time was easier for me.

Setup network, ssh, hosts and selinux

/etc/hosts and hostname

The packstack scripts need the hosts file and the hostname setup correctly.

# hostnamectl set-hostname kozik4.lan
# vi /etc/hostname
kozik4.lan
# vi /etc/hosts
127.0.0.1 kozik4.lan kozik4 localhost.localdomain localhost
129.168.100.154 kozik4.lan kozik4

SELinux

I turn SELinux to permissive mode ; edit a line in SElinux config file:

# setenforce permissive
# vi /etc/selinux/config
...
SELINUX=permissive
...

sshd for root login

OpenStack’s install script requires root access for ssh login. To setup ssh:

# vi /etc/ssh/sshd_config
...
PermitRootLogin yes
...
# systemctl  enable sshd.service
# systemctl  start sshd.service

When done with the install, I will turned off root login access.

Network Manager

Following the RDO Quickstart guide, turn off NetworkManager and turn on network

# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service
# systemctl enable network.service
# systemctl start network.service

Then reboot. Make sure basic networking is running. Verify ssh for root login works.  Use another PC on the same LAN and verify ssh into the server works.

Install OpenStack Kilo on CENTOS7

In the root login, run the following steps. Make sure each one runs successfully before starting the next.

# yum update -y
# yum install -y https://rdoproject.org/repos/rdo-release.rpm
# yum install -y openstack-packstack

At this point, I insert a work around that is specific to my setup. This particular CENTOS7 distribution pulls in mariaDB as part of KDE. I found that this created a conflict with the packstack scripts. As I documented in a previous post, uninstall mariaDB as follows.

# yum remove mariadb-server

Run packstack

Now run the main install script, packstack. Note, I am adding orchestration in addition to the default install.

# packstack --allinone --os-heat-install=y

Note that this last step is the big installation step. It runs for a long time, and if it fails, it will give detailed error messages and pointers to log files. If you run into troubles, apply workarounds and to re-try, run packstack with an answer file, as follows:

# packstack  --answer-file=packstack-answers-20150704-200908.txt

Assuming the packstack install works, verify the basic dashboard works by bringing-up the login screen. For my home server, http://192.168.100.154/dashboard:

Setup Bridging

In order for the OpenStack VM to network with my home lan, I needed to get bridging setup. First, I made the br-ex bridge points to the IP address/gateway that I originally setup for the NIC (in CENTOS7, the NIC is assigned a name enp3s0).

I edited ifcfg-br-ex as follows:

# vi /etc/sysconfig/network-scripts/ifcfg-br-ex
DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=192.168.100.154
NETMASK=255.255.255.0
ONBOOT=yes
GATEWAY=192.168.100.162
DNS1=8.8.8.8
DNS2=8.8.4.4

By default, the NIC (enp3s0) has the external IP address and gateway. Since we moved that to the external bridge, we need to make the NIC card look like a member of the bridge. I edited the ifcfg-enp3s0 as follows:

# vi /etc/sysconfig/network-scripts/ifcfg-enp3s0
DEVICE="enp3s0"
ONBOOT=yes
HWADDR=40:16:7E:B1:64:CD
TYPE=OVSPort
DEVICETYPE="ovs"
OVS_BRIDGE="br-ex"

At this point, I rebooted. When done, check everything. Verify ping to the Internet, verify the same, inbound. Verify ssh, both inbound and outbound.

For reference, I record my network setup here:

[root@kozik4 ~]# ifconfig
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.154  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::4216:7eff:feb1:64cd  prefixlen 64  scopeid 0x20
        ether 40:16:7e:b1:64:cd  txqueuelen 0  (Ethernet)
        RX packets 142320  bytes 27075628 (25.8 MiB)
        RX errors 0  dropped 15257  overruns 0  frame 0
        TX packets 3632  bytes 1435026 (1.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::4216:7eff:feb1:64cd  prefixlen 64  scopeid 0x20
        ether 40:16:7e:b1:64:cd  txqueuelen 1000  (Ethernet)
        RX packets 149724  bytes 27519634 (26.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4016  bytes 1460686 (1.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 0  (Local Loopback)
        RX packets 2627327  bytes 289453679 (276.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2627327  bytes 289453679 (276.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
		
# ip route show
default via 192.168.100.162 dev br-ex
169.254.0.0/16 dev enp3s0  scope link  metric 1002
169.254.0.0/16 dev br-ex  scope link  metric 1004
192.168.100.0/24 dev br-ex  proto kernel  scope link  src 192.168.100.154

OpenStack Dashboard

The dashboard is found at http://192.168.100.154/dashboard. The User Name is admin, the password for the dashboard is found in the /root/keystone_admin file. By default, I was able to access the dashboard from any PC on my home lan. For access from outside of my home LAN, I setup a NAT mapping in my home gateway, but I had to setup an alias in the OpenStack horizon apache configuration.

# vi /etc/httpd/conf.d/15-horizon_vhost.conf
...
ServerName kozik4.lan
ServerAlias os.mydomain.net # Add this line
...
 
# systemctl restart httpd.service

The name os.mydomain.net is a sub-domain name that I own, where I map it to the Internet routable IP address my ISP gives me. Verifiy that http://os.mydomain.net/dashboard works.

Once  logged in,  the dashboard shows the network setup that packstack installs for us by default.  It sets up a private and public networks IP addresses that don’t match my needs.  So I need to clear this out.   The way OpenStack works, you cannot delete everything in one hammer-style step; you need to disassemble the networking one step at a time.

First, you need to delete the router, then delete the networks.

Remove the packstack default router and networks

Delete the pre-installed router

This step deletes the default router that packstack setup for us. The dashboard gives a nice GUI to do this.  Navigate to Admin->Routers.

Admin->Routers

Before we can delete router1, we need to delete its interfaces.  Click on “router1″

Admin->Routers->router1
Using he GUI, we can delete these two interfaces, and then we can delete the router.

But for my own education and the potential automation of future installs, I figured out how to do this with  OpenStack command line scripts.  The easiest way to display this is to screen scrape my putty commands and insert it inline below:

Go back to the dashboard Admin->Routers page, verify that the router has been cleared. I know, the command line steps are alot more difficult than clicking the “Delete Router” button, but this is how I learn.

Admin->Routers

Delete Pre-Installed Networks

From the dashboard Admin->Networks. We want to delete the two networks packstack setup for us. In packstack (OpenStack?) terminology, the private network is the range of IP addresses used by the virtual machines used by the admin project within this OpenStack installation. The public network maps to the interface that routes packets to outside networks… in this case, the public network will eventually be assigned addresses that fit within my home lan (not Internet addressable IP address).

The Networks dashboard shows two networks. I want to remove them. It turns out you need to click on each of the networks and delete the subnets attached to the network.  On the dash board it is pretty easy to do.

Admin->Networks

Here’s the command lines that will delete these two networks.  Note, again, I typed the commands into my putty screen, and scraped them and inserted them inline below.

Verify that the Networks are gone in the dashboard.

Admin->Networks

Ok, to this point we have a clean slate ready to bring in images, spin up instances, and network them together.

References

• RDO Quickstart
• Neutron with existing external network
• Openstack Juno- RDO Packstack deployment to an external network & config via Neutron
• Installing OpenStack Kilo RDO on CentOS With Packstack

The post OpenStack Kilo on CENTOS7 using packstack on home server appeared first on JackKozik.com.

For my RDO packstack Kilo install setup, I followed the normal Quick Start  steps on a bare metal installed version of CENTOS 7 (CentOS-7-x86_64-LiveKDE-1503).

I ran the following step in the install guide:

# packstack --allinone

The packstack installed failed with the following error on the console:

Error: Execution of '/usr/bin/rpm -e mariadb-server-5.5.41-2.el7_0.x86_64' returned 1: error: Failed dependencies:
You will find full trace in log /var/tmp/packstack/20150704-200908-

This is an error pointing to the following log file entry:

Error: Execution of '/usr/bin/rpm -e mariadb-server-5.5.41-2.el7_0.x86_64' returned 1: error: Failed dependencies:
        mariadb-server is needed by (installed) akonadi-mysql-1.9.2-4.el7.x86_64

This is only my second install using packstack, and it is my first attempt at installing RDO packstack Kilo; so, I wasn’t familiar with the troubleshoot this kind of problem. It didn’t make sense to me that packstack would be trying to uninstall (rpm -e) MariaDB. The error indicates that the uninstall wouldn’t work because another package akonadi-mysql was using it — right? is that how I read this?  FYI:  Akonadi is a storage service that runs under KDE… I wasn’t familiar with it.

Browsing the RDO Workaround archives , I found a short article on this topic: Packstack fails when mariadb-server is installed. The body of the article shows a log file message that is different enough from mine that I didn’t find it right away.

I tried the recommended fix to uninstall MariaDB and re-run RDO packstack Kilo:

# yum remove mariadb-server
# packstack  --answer-file=packstack-answers-20150704-200908.txt

This fixed my problem!

I was able to run packstack to completion and bring up the openstack horizon dashboard. Note: I didn’t re-run packstack –allinone; I followed the packstack workflow requirement to re-run an install using the answer file previously generated.

Since the workaround was written for Juno and Fedora 20, I thought the fix was just a coincidence, but in reading the details, the original problem was triggered by installing KDE ontop of Fedora 20. Since I picked a KDE distribution of CENTOS7, maybe my problem and the original workaround write-up are related?!

Respectfully submitted,
Jack

The post Openstack RDO packstack Kilo install stuck on CENTOS 7 – MariaDB conflict appeared first on JackKozik.com.

I needed web access to my openstack host. I needed web access to each of my instances, which are running virtually on the same host. Further, since I am running all of this on one server in my home network, I need to somehow map all of this to one external IP address.

This is nothing too new to me. I have lots of vintages of Linux servers in my basement, and I sort of know the ropes around setting up NAT-ing, Virtual Servers, and proxies. My question was: what’s the best practice? What would be the easiest?

I couldn’t find anything directly on this (let me know if you have a reference). So here’s what I decided to do.

Enable Openstack Dashboard Network Access

By default, the Openstack Horizon Django configuration strictly controls who can get access. It’s roughly localhost only. For testing purposes, I went into the settings file and removed all restrictions:

$ cd /etc/openstack-dashboard
$ vi local_settings
...
#ALLOWED_HOSTS = ['horizon.example.com', ]
ALLOWED_HOSTS = ['*']
ZZ
$ systemctl restart httpd.service

I tried making a restrictive list, but it kept getting in my way. When done setting up, I will lock this up.

I then verified from a different PC in the same subnet that http://192.168.100.154/dashboard works.

Map Openstack Host to External IP Address

Using my home router, I configured an address mapping between port 80 and my Openstack host. Here’s the screen shot:

Port Forwarding Table from my home router

Now verify that http://my.external.IP.address/dashboard works.

Setup an Openstack Subdomain Name

One of my domain names, jackkozik.net points to my home router’s IP address. I setup an Openstack subdomain name, using my zoneedit account — I used os.jackkozik.net. Sorry no screen shot. I am (perhaps too liberally) showing my domain name, but I am reluctant to show my IP addresses. Zoneedit is pretty quick, but distributing a new subdomain address takes anywhere from 0 to 60 minutes.

I then edit Openstack’s virtual server configuration adding os.jackkozik.net as a ServerAlias, as follows:

$ cd /etc/httpd/conf.d
$ vi 15-horizon_vhost.conf
...
<VirtualHost *:80>
ServerName kozik4.lan
ServerAlias os.jackkozik.net # Add this line
...
ZZ
$ systemctl restart httpd.service

Then assuming the subdomain has had a chance to get distributed, verify http://os.jackkozik.net/dashboard.

Openstack’s install scripts automatically setup this VirtualHost.

Create Subdomains for Each of My Instances

Within Openstack, I create instances that are automatically assigned IP addresses from a pool in the range of 192.168.100.100-119. Of course these instances are accessible from my home network (eg http://192.168.100.100 displays a nice Apache default screen). But I only have one external IP address and I need a mechanism to for external web access.

Absent any better approach (I hope to find one!), I am using Apache’s ProxyPass capability. I have used this for physical servers, why not use it for virtual machines?!

For starters, I created another subdomain in zoneedit. I decided to name each external instance with a letter followed by the least significant digits from the IP address. My first subdomain is named f100: That is, it is a Fedora instance and it’s running an instance mapped to 192.168.100.100. In zoneedit, I enter the subdomain f100.jackkozik.net, and I put the same external IP address that I used for os.jackkozik.net.

Within the Apache configuration files, I created a virtual server named f100.jackkozik.net, and used ProxyPass to map it to (redirect it to?) the web server running on 192.168.100.100. See the following config file:

$ cd /etc/httpd/conf.d
$ vi openstackInstances_vhost.conf
# This file configures all the proxy modules:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<VirtualHost *:80>
ServerName f100.jackkozik.net
ProxyPreserveHost On
ProxyPass / http://192.168.100.100/
ProxyPassReverse / http://192.168.100.100/
</VirtualHost>
ZZ
$ systemctl restart httpd.service

I created this file and put it in the conf.d directory. It automatically gets read whenever the apache web server starts.

From here, allowing enough time for zoneedit to work, I verified that http://f100.jackkozik.net worked from both my home network and from an outside network (I sometime use my desktop PC at work test this; more commonly I use the Chrome browser on my Android phone).

I edit this file for each new instance I setup.

So each of my instances think they are sitting on the internet, but really the Openstack host Apache server and my home network router’s NAT function are fooling it.

Fix ALLOWED_HOSTS

Finally, once I got everything working, I fixed ALLOWED_HOSTS to permit any traffic from my home subnet and only allow requests from URL os.jackkozik.net from the Internet. See following:

$ cd /etc/openstack-dashboard
$ vi local_settings
...
ALLOWED_HOSTS = ['localhost', 'os.jackkozik.net', 'kozik4.lan', ]
#ALLOWED_HOSTS = ['*']
ZZ
$ systemctl restart httpd.service

The post Setting up Virtual Servers in Openstack environment appeared first on JackKozik.com.

This posting is part 2.  With the installation from part 1, I can now use the Openstack Dashboard.  It is a nice web interface that contains straight forward menus.  In the sections below, I will show screen captures from a web browser connected to the Dashboard; I will also show some command line text from a putty window.

This writeup will show steps for setting up a public subnet that links Openstack to my home network and setting up a private subnet for my guest instances to use.  Then I will show how to create an instance using the bare-bones cirros image.  And finally, I’ll install into the image repository a Fedora 20 cloud image and spin it up with a basic web server.

Since Openstack and the Openstack Dashboard are new to me,  I do all of this with the generous help of the references listed below, especially recognizing Seth Jenning’s excellent  Openstack Icehouse on Fedora 20 using RDO video.

Create a public network.

Starting with the Openstack Dashboard, logged in as admin, create a public network.  My home network is 192.168.100.0/24.  The IP address 192.168.100.163 is the address of my home router, gateway to the internet. My Openstack Icehouse host is 192.168.100.154.  And Openstack needs a subnet, referred to as public, that sits in this address range.

The naming convention of calling the network 192.168.100.0/24 public started with the packstack install scripts.  In the context of Openstack, this network is the one with a gateway to the internet and thus it is referred to as public, even though we know the internet defines 192.168.x.x IP addresses as private.

Openstack Dashboard Menu: Admin->Networks->Create Network

Openstack Dashboard Menu: Admin->Networks->public->Create Subnet

Openstack Dashboard Menu: Admin->Networks->public->Create Subnet 2

Create a private subnet

Next, create  a subnet that is private to the Openstack host.  The addresses must be different from the public_subnet.  These addresses will never leave the Openstack host and it’s underlying Open vSwitch network address space.   The references use 10.0.0.0/24 as the network and 10.0.0.1 as the gateway address — and that’s what I use below.  Further, the guest instances each need to be given an IP address, and 10.0.0.2, 10.0.0.20 address are what I choose to be the range for a DHCP address pool.

Openstack Dashboard Menu: Project->Network->Network Topology->Create Network — “private”

Openstack Dashboard Menu: Project->Network->Network Topology->Create Network->Subnet

Openstack Dashboard Menu: Project->Network->Network Topology->Create Network->Subnet Details

Create a router

Ok, there’s a public and a private subnet defined.  Openstack Dashboard has a really simple way to connect them together with a router function.  Create a router, define a default gateway and then add interfaces to private subnets.

Openstack Dashboard Menu: Projects->Network Topology->Create Router

Openstack Dashboard Menu: Project->Routers->Set Gateway

Openstack Dashboard Menu: Project->Routers->router->Add Interface

Verify Network Topology

All the steps upto this point were building a network into which virtual machines connect to the home LAN.  Run the Dashboard command below to see two subnets connect to a router.  The public subnet is on the home LAN.  The private subnet is the address space where the guests instances will connect.

Openstack Dashboard Menu: Project->Network Topology

Setup Security Group Rules

The references suggest that for trial/learning purposes, the Security Group Rules should be wide open.  The idea is while learning the technology, the security settings can obscure basic setup issues.  In the long run, this needs to be managed more carefully.

First, remove the default rules that packstack setup, then install rules that permit incoming and outgoing TCP/UDP/ICMP — all ports.

Openstack Dashboard Menu: Project->Compute->Access and Security->default

Delete all the default rules and rebuild the rules so that the Security Group Rules table looks as follows:

Setup an ssh key pair

Using the normal ssh tools, make an ssh public and private key pair.  The Openstack Dashboard lets you cut / paste your own public key into the project.  The instances that get created will have the  public key pre-installed into it.  To access instances that Openstack creates, use the private key as an option in an ssh command line.

Go to the root login of the Openstack host, at the command prompt create a key and copy the public key into the clipboard.

[root@kozik4 ~]# ssh-keygen -t rsa -f cloud.key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in cloud.key.
Your public key has been saved in cloud.key.pub.
The key fingerprint is:
36:37:4d:d3:5b:82:45:53:48:98:24:00:8b:0b:3b:06 root@kozik4.lan
The key's randomart image is:
+--[ RSA 2048]----+
|      .......==o.|
|     . .   .o+.. |
|E . . .     + o .|
| . o .     o . + |
|  + .   S o . .  |
| . .   . o .     |
|                 |
|                 |
|                 |
+-----------------+
[root@kozik4 ~]# ls
anaconda-ks.cfg  ifconfig5.out         packstack-answers-20140803-201418.txt
cloud.key        installpackstack.log  packstack.log
cloud.key.pub    keystonerc_admin      rdorelease.log
ifconfig1.out    keystonerc_demo       runpackstack.log
ifconfig2.out    ovs1.out              yumupdate.log
ifconfig3.out    ovs2.out
ifconfig4.out    ovs3.out
[root@kozik4 ~]# cat cloud.key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDijKn/k5ejNii3SaNugO75Njz1LQHyDDwI5blZO4+CZTRL/O/8czffrUUfK8+j3QjAx7MByNJVkj8YCGtOAYv5wCFEhzkRhqNNJlH235L++QV6ai/XPD7b0VcqhCjQTkDIfyBMp7fZO+D0BGdvTjBiQXIJdZLqZWV2j9qH8EHHS55OlOXpAAcMHvRRgWFtMdn5YSLUcq8X5HRtvfesLL7quJmNDc8/rS6mhmL/NFU56r+SJpHvr7N59U7ywNejLgFp6hfz4zZw3nWDH9y+by1zdWbNfATIO362SRue+FvuF060ss4Ciesuqw5v3tJMeyq9JM41lu8fQaIeBqoJTB43 root@kozik4.lan
[root@kozik4 ~]#

In putty screen like the above example, select the text output from the ‘cat cloud.key.pub’ command and paste into the Openstack Dashboard as follows.

Openstack Dashboard Menu: Project->Access & Security->Key Pairs->Import Key Pair

Launch Test Instance ‘cirros’ and assign floating IP

To help verify that the Openstack packstack installed correctly, spin-up the barebones cirros image.  This image is a really small linux distribution.  I’ve never heard of cirros, but I get the purpose of it.  My initial setup had troubles, and cirros helped me trouble shoot basic setup problems.  I was glad the initial install pulled it in.

The following steps startup an instance, link it to the private subnet, and map the private IP address of the instance to a floating IP address on the public subnet.  Floating IP addresses were new to me, and it wasn’t obvious how they should be used, at first.  I think of it as a generalized NATing function, that lets me hide my home network topology from the Openstack instances.

Openstack Dashboard Menu: Project->Images->Launch->Details

Connect the instance to the private subnet.  Note: the web page below requires you to drag the private line and drop it into the Selected Networks cyan-colored bar.

Openstack Dashboard Menu: Project->Images->Launch->Networking

Verify the test instance is running:

Openstack Dashboard Menu: Project->Instances

Allocate a Floating IP address

Openstack Dashboard Menu: Projects->Access & Security->Floating IPs->Allocate IP to Project

Associate the instance’s private IP address to an IP address on the public subnet.

Openstack Dashboard Menu: Project->Access & Security->Floating IP->Associate

Verify that the instance has two IP addresses and is running ok.

Openstack Dashboard Menu: Project->Instance

Go back to the 192.168.100.154 host putty prompt (root login, home directory).  Verify that we can setup an ssh connection to the new instance. The default login id is cirros. The Instances web page above tells us to use the 192.168.100.101.

# ssh -i cloud.key cirros@192.168.100.101
The authenticity of host '192.168.100.101 (192.168.100.101)' can't be established.
RSA key fingerprint is 34:51:4c:22:c3:67:d3:47:38:83:c2:ee:55:0f:4b:e5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.100.101' (RSA) to the list of known hosts.

$ ifconfig
eth0      Link encap:Ethernet  HWaddr FA:16:3E:62:7D:36
          inet addr:10.0.0.3  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::f816:3eff:fe62:7d36/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1

$ ping yahoo.com
PING yahoo.com (98.139.183.24): 56 data bytes
64 bytes from 98.139.183.24: seq=0 ttl=47 time=49.484 ms
64 bytes from 98.139.183.24: seq=1 ttl=47 time=121.366 ms
64 bytes from 98.139.183.24: seq=2 ttl=47 time=81.164 ms

Note: the ifconfig shows that the instance only knows about the private_subnet address 10.0.0.3. Also, an important test to verify: check that the instance can access the internet, I used ping yahoo.com.

Create a Fedora 20 instance

The cirros instance installation steps above helped to verify that basic functionality worked.  But cirros is not a linux distribution I want to use; I want to use the latest version of Fedora.  In this section I repeat some of the steps from the previous section to get a Fedora 20 instance started.  There’s enough different here that I wanted to document it.

From the Fedora In the Cloud web page, right click the 64-bit qcow2 image and “Copy Link Address.”  The Images page has an option to import new images using a URL.

Create an image from this URL:

Openstack Dashboard Menu: Project->Create Image

Following the same steps as the cirros image, launch the Fedora 20 image.

Openstack Dashboard Menu: Project->Instance->Launch Instance

Be sure to click the Networking tab and select private subnet, then click on Launch.

Once the instance is running, allocate a Floating IP.  Go to the Projects->Access & Security->Floating IP menu. First run Allocate IP to Project then Manage Floating IP Associations for the Fedora 20 instance… just like we did for the cirros instance.

The Instance Dashboard page now shows 2 instances.

Openstack Dashboard Menu: Project->Instance

And the Network Topology page gives a nice picture of how everything is wired together.

Openstack Dashboard Menu:  Project->Network->Network Topology

So, just like with cirros, go to the Openstack host root login  prompt and ssh to the Fedora instance.  The Instance page above show 192.168.100.102 as the IP address.

# ssh -i cloud.key fedora@192.168.100.102
The authenticity of host '192.168.100.102 (192.168.100.102)' can't be established.
RSA key fingerprint is 2e:b3:7b:6b:06:43:cf:d5:95:95:49:38:5f:ab:20:39.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.100.102' (RSA) to the list of known hosts.
[fedora@fedora-20 ~]$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.4  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::f816:3eff:fe9b:baf5  prefixlen 64  scopeid 0x20																					
        ether fa:16:3e:9b:ba:f5  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 0  (Local Loopback)

[fedora@fedora-20 ~]$ ping yahoo.com
PING yahoo.com (206.190.36.45) 56(84) bytes of data.
64 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=1 ttl=49 time=1         06 ms
64 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=2 ttl=49 time=1         56 ms
64 bytes from ir1.fp.vip.gq1.yahoo.com (206.190.36.45): icmp_seq=3 ttl=49 time=1         02 ms

Note:  the Fedora guest instance only knows the private address 10.0.0.4.  The default login id, fedora, has sudo permissions and access to the root login is done with a ‘sudo su -’ command. It is important also to verify that it can talk to the outside world, and thus verify that ping yahoo.com works.

To further test my Fedora 20 instance, I switched over to the Fedora 20 instance root login and installed apache:

[fedora@fedora-20 ~]$ sudo su -
[root@fedora-20 ~]# yum groupinstall "Web Server"
[root@fedora-20 ~]# systemctl enable httpd.service
[root@fedora-20 ~]# systemctl start  httpd.service

From here, I go to another PC in my home network and verify that the default web server works.

References

• Openstack Icehouse on Fedora 20 using RDO
• RDO Quickstart
• Fedora in the Cloud
• Running an Instance
• Difference between Floating IP and private IP
• My RDO Installation Procedure
• Install and Configure Openstack Neutron
• Openstack Packstack with External Connectivity

The post Openstack Icehouse on home network – part 2 appeared first on JackKozik.com.

Install Fedora 20

I have been using Fedora/Redhat for years, but the most recent install I did was Fedora 16, so I am a little out of date with the new processes and procedures. For me, my first step was to go to the Fedora distribution page and down load an ISO to make an install DVD (I selected the Fedora 20 Desktop Edition Live Media).

My hardware was brand new, and I installed Fedora 20 onto a 2T RAID Intel PC box. I let the Fedora installer format my disks to the default settings. I configured a login and timezone and let the install run. Everything worked the first time.

The next couple of steps I follow by sitting infront of the console for my PC. I usually do everything through ssh and/or VNC, but for Openstack setup, I stayed at the console.

Prep for Openstack Icehouse on Fedora 20: Static IP, /etc/hosts, sshd, NetworkManager

Static IP Address

The Fedora install configures the host  to use DHCP to get the initial IP address. The host needs a static IP for Openstack setup to work.  The default  network-scripts for the main host interface are easily edited. For my install, the  interface is named p2p1 (in the old days this would be named eth0).

Configure the ifcfg-p2p1 script to look something like the following:

# vi /etc/sysconfig/network-scripts/ifcfg-p2p1
TYPE="Ethernet"
BOOTPROTO=static
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
NAME="p2p1"
UUID="42a635ee-281c-44fc-9e16-f4e23111d4fb"
ONBOOT="yes"
HWADDR=40:16:7E:B1:64:CD
IPADDR=192.168.100.154
PREFIX=24
GATEWAY=192.168.100.163
DNS1=8.8.8.8
DNS2=192.168.100.163
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

Note: the host’s IP address and its gateway IP address are inside my private IP address range (192.168.100.0/24). I will use these addresses throughout my write-up.

Before I reboot, I want to change a couple of other host configurations.

/etc/hosts and hostname

It turns hostname must be setup right or the packstack script will get stuck.

# hostname kozik4.lan
# vi /etc/hostname
kozik4.lan
# vi /etc/hosts
127.0.0.1 kozik4.lan kozik4 localhost.localdomain localhost
129.168.100.154 kozik4.lan kozik4

Note: .lan is my home network private domain name. I don’t share .lan publically.

SELinux

I turn off SELinux; edit a line in SElinux config file:

# setenforce permissive
# vi /etc/selinux/config
...
SELINUX=permissive
...

sshd for root

Openstack’s install script requires root access for ssh login. To setup ssh:

# vi /etc/ssh/sshd_config
...
PermitRootLogin yes
...
# systemctl  enable sshd.service
# systemctl  start sshd.service

firewalld and NetworkManager

Disable firewalld and NetworkManager as recommended in several of the references.

systemctl disable firewalld

systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
systemctl enable network.service
systemctl start network.service

From here,  reboot. Everything should come back ok. Nothing really changed except switching from dynamic to static IP addressing.  Verify from another PC that ssh root@192.168.100.154 works. Verify that ping yahoo.com works.

For reference, ifconfig looks like this:

# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 0  (Local Loopback)

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.154  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::4216:7eff:feb1:64cd  prefixlen 64  scopeid 0x20																				
        ether 40:16:7e:b1:64:cd  txqueuelen 1000  (Ethernet)

Install/update Openstack software

From the host’s root login at /root, run each of the following yum installs, one at a time, verifying that they complete successfully.

yum update -y
yum install -y http://rdo.fedorapeople.org/rdo-release.rpm
yum install -y openstack-packstack 
packstack --allinone --provision-all-in-one-ovs-bridge=n

The last install is the big one.  The packstack script is what puts OpenStack Icehouse on Fedora 20; It will take awhile to run.

It took me a couple of tries to get the last step to work. The hostname must cleanly resolve for the packstack scripts to work. Further, the packstack scripts runs ssh root@192.168.100.154. If this is not setup right, packstack will fail. Note: the packstack script prompts you for your root password.

Setup Open vSwitch Bridging

Once done, the packstack scripts sets up an Open vSwitch network as summarized here.

# ifconfig
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::3442:c4ff:fe5c:874b  prefixlen 64  scopeid 0x20																				
        ether 36:42:c4:5c:87:4b  txqueuelen 0  (Ethernet)

br-int: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::a817:aff:fee8:934c  prefixlen 64  scopeid 0x20																				
        ether aa:17:0a:e8:93:4c  txqueuelen 0  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 0  (Local Loopback)

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.154  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::4216:7eff:feb1:64cd  prefixlen 64  scopeid 0x20																				
        ether 40:16:7e:b1:64:cd  txqueuelen 1000  (Ethernet)

It turns out that this setup does not connect with the outside world — the default install scripts don’t have a place for me to tell it my home network setup (that I know of). The br-ex needs to connect to the outside world and p2p1 needs to connect to br-ex.

There’s some discussion in RDO community to make it easier for novices like me to connect the packstack install to a home network’s subnet. But for now, there’s a few simple steps to follow to get  the PC’s main interface to connect to the Open vSwitch infrastructure setup by packstack.

For starters, connect the external bridge (named br-ex) to the home network,  by editing the br-ex config file that packstack creates:

# vi /etc/sysconfig/network-scripts/ifcfg-br-ex
DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=192.168.100.154
NETMASK=255.255.255.0
GATEWAY=192.168.100.163
DNS1=8.8.8.8
ONBOOT=yes

Note: the br-ex bridge has the IP address and GATEWAY address that I would normally use to access the PC.

And, the host’s interface p2p1 needs to be updated to become Open vSwitch aware, editting the ifcfg-p2p1 file to look like the following:

# vi /etc/sysconfig/network-scripts/ifcfg-p2p1
DEVICE=p2p1
ONBOOT="yes"
HWADDR="40:16:7E:B1:64:CD"
TYPE="OVSPort"
DEVICETYPE="ovs"
OVS_BRIDGE="br-ex"

And one more thing, the openstack dashboard access is limited to localhost only.  Remove this access control, for now.

# vi /etc/openstack-dashboard/local_settings
#ALLOWED_HOSTS = ['192.168.100.154', 'kozik4.lan', 'localhost', ]
ALLOWED_HOSTS = ['*', ]

From here, reboot. When the computer comes back up,  verify that basic network looks good. Here’s what ifconfig looks like:

# ifconfig
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.154  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::4216:7eff:feb1:64cd  prefixlen 64  scopeid 0x20																				
        ether 40:16:7e:b1:64:cd  txqueuelen 0  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 0  (Local Loopback)

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::4216:7eff:feb1:64cd  prefixlen 64  scopeid 0x20																				
        ether 40:16:7e:b1:64:cd  txqueuelen 1000  (Ethernet)
# ovs-vsctl list-ports br-ex
p2p1

Above, verify that  the host’s IP address is tied to br-ex and the interface p2p1 shows as a port on br-ex. These look good. Also verify that ssh root@192.168.100.154 works; then go to another PC and run the same command. Finally, to make sure that the host can route to the internet, ping yahoo.com. These basic plumbing tests are needed for the rest of openstack to work, and in my case, it didn’t work the first time, and these basic sanity tests helped me troubleshoot.

A stuck point for me:  when I reached this point one time before, I couldn’t ping yahoo.com.  Which was disappointing because everything else worked.  So I ran the following command:

# ip route show
default via 192.168.100.163 dev br-ex  # Verify this line is here!!
169.254.0.0/16 dev p2p1  scope link  metric 1002
169.254.0.0/16 dev br-ex  scope link  metric 1004
169.254.0.0/16 dev br-int  scope link  metric 1005
192.168.100.0/24 dev br-ex  proto kernel  scope link  src 192.168.100.154

Unlike what I list above, the default route didn’t get configured for my host’s network.  I found some helpful notes that suggested manually adding it in (ip route add default via…).  That worked, but what worked better for me was to disable NetworkManager (see steps I list earlier).

As an aside, the ip route show output above works for me, but doesn’t look right.  The lines that begin with 169.254.0.0 shouldn’t be there (I think).  Something is not quite right, but I don’t know if it is worth fixing.  Anyway…

What I get now, is every time I boot, I get a clean network setup, incoming and outgoing.

Ok, once the PC’s network setup is stable after boot,  run the openstack-status script; the script returns a long list of status lines and two key lines indicate a failed status.

# openstack-status
...
neutron-server:                         failed
rabbitmq-server:                        failed
...

For whatever reason (probably some fault in my setup steps), rabbitmq and neutron servers failed to start. I saw this issue addressed in the video referenced below; these services are easily restarted as shown below

systemctl start rabbitmq-server.service
systemctl start neutron-server.service

… everything comes back and the next steps work fine.

Openstack Dashboard

As a last step, go to a web browser and verify that you can login to the openstack dashboard. Once this step works, you should be able to do everything from a web browser or Putty terminal.

The dashboard is found at http://192.168.100.154/dashboard. The User Name is admin, the password for the dashboard is found in the keystone_admin file.  Once you can login, then installing OpenStack Icehouse on Fedora 20 is complete.

Once we are logged in, we need to navigate to the Admin->Routers page and delete the default router that packstack setup for us, select all the routers (only one) and then click on the “Delete Routers” button below:

Then we need to go to the Admin->Networks page and delete the networks.  Select all the Networks, then click on the “Delete Networks” button below:

With the demo network and router setup re-initialized,  we have a clean slate that we can build upon.

End of part 1.  I next need to writeup the steps to configure a OpenStack, including how to load images, create instances, network those instances together, and bridge them to the home network.  In addition, I will writeup how to map a “floating IP address” between an instance and my home network.   All for next time.

References

• Openstack Icehouse on Fedora 20 using RDO
• RDO Quickstart
• How To: install packstack allinone on Fedora 20 with an existing external network 
• Fedora 20 with existing network
• OPENSTACK PACKSTACK INSTALLATION WITH EXTERNAL CONNECTIVITY
• RDO Icehouse: Configuring the external bridge

The post OpenStack Icehouse on Fedora 20 using packstack on home PC appeared first on JackKozik.com.

SIM Card

In my Audi S7, it has a T-Mobile SIM card, connecting it to the T-Mobile US 3G/UMTS network – the first 6 months of usage is free.  I have turned on the Audi Connect service, linked it with my Google account, linked it with the iPhone App.  I even turned on the Wifi hotspot in my car.  It all works pretty good.  My T-Mobile service is data-only — I see no way to use the TMO voice or text features.

Here are my notes.

Audi Connect iPhone App

The Audi S7 has a simple iPhone App.  Two useful features:

• Online Destinations. I can enter addresses onto an Online Destinations form; these addresses will show-up on my Audi S7′s navigation menu.
• Car Finder.  I setup the Audi S7 to report it’s GPS coordinates when ever the car shuts off.  The Car Finder feature lets me find where my car is parked.  This is a nice feature, but a little gimmicky for me. You could also find vin for free here.

Car Finder App

Google Maps – “Save to Car”

The Audi Connect service also ties into Google Maps.  When I registered my google login with Audi Connect (my.audi.com, Services -> Dest From Google Maps), Google maps added an option to let me save a map address to my car.  Here’s a Google Maps screen shot:

http://maps.google.com

So if I am going to visit some place new to me, I can look up the address on Google Maps, save it with the “Send to Car” option and have the address show on a menu in the Audi S7 Navigation menu.  Really cool.  I like this feature.

I can erase saved destinations using the mobile app.

myAudi Portal – my.audi.com

To setup the Audi Connected Car service, I got a login on the myAudi portal, my.audi.com. The portal helped me setup the Destination From Google Maps and Destination Input Services.  The portal required me to enter my VIN number, and it gave me a key to use when setting up the car.

Here’s a snapshot from the portal:

http://my.audi.com

Audi Connect

 The MyAudiConnect website links the Audi’s TMO service to the myAudi service.  The key parameters are the 19-20 characters printed on the SIM card (technically known as an ICCID — see the SIM wiki) and the car’s 17 character VIN number.     The Audi Connect Car uses T-Mobile.  The My Audi Connect portal’s drop-down menu also lets you choose AT&T.

As near as I can tell, I will never get a bill directly from T-Mobile.  It appears to come from Audi — but I am sure T-Mobile is getting paid.

https://myaudiconnect.com

The screenshot above indicates that my Account is active, but my Audi Connect and Wireless Networks are inactive — that’s correct, the car is parked, off, in my driveway. Also, it is hard to read, but the two airbrushed-out fields above are the car’s VIN number and the T-Mobile SIM card number.   Sorry if I got carried away with the red stuff.

Dashboard View

The view from the dashboard in the car is pretty intuitive.  When in the Navigation mode, the following screen displays when you selection “Destinations”

Navigation->Destination->Online destinations

The display shows an “Online destination” option and from there, the destinations that you set using the Google Maps “Send to Car” option are found.

A nice feature of the Audi Connected Car is the navigation  view superimposes satellite maps from Google Maps, as seen below:

Navigation Map w/Satellite View

Some additional Google Maps features of note:

• Google Search.  The traditional in-car Navigation systems have a very good database of point-of-interests and street address.  The Audi Connected Car lets you use a direct Google search to find nearby or destination-city destinations.
• The Google Maps display settings let you put Places, Businesses, Panoramio pictures, or even pointers to WIKipedia

Below are screen shots directly from Audi Connect information services.  First there’s a menu of simple services (not linked with Google), and below that is a screen capture of a radar weather map.  The content is formatted special for Audi and is not real websurfing.

Menu->Info->Audi Connect

Menu->Info->Audi Connect->Weather Info

SIM Card Slot

The car’s dashboard has a slot, hidden by a folding door, where the SIM card slot and two SD card slots are found.  Note:  only the SIM card is plugged in for the picture below.

SIM Card Slot

In Car WIFI

The car lets you setup a WIFI hotspot that routes through the TMO UMTS/3G data service.  I tried it; it worked ok, but it’s not as fast as our 4G/LTE data service and I am not really sure why I’d ever want to use this — maybe for a guest?

Anyway, I ran a speedtest on the WIFI and for my neighborhood, the service is 1Meg down / 0.5 up.  Here’s a screenshot from my mobile:

References

• Audi Connect Operating Manual
• Audi Connect FAQ
• My Audi Connect Portal (needs login)

The post Audi Connected Car – 2014 S7 appeared first on JackKozik.com.

For my own education, I decided to use this project as a trigger to learn Node.js.

I had been following the progress of the node community and some of the organizations at work had started using node, so I decided to give it a try. I had been using JavaScript for quite awhile doing front end programming in my browser applications and felt that it shouldn’t be too hard for me to learn.

The notes that follow capture some of my learnings and record some of the steps I followed to design and setup my new web service.

Install Node.js on my Fedora Server

I am a system admin of my own Fedora server, and I was looking to do a full install of nodejs. If you have a new Fedora sever (Fedora 18+), you just use “yum install nodejs” — but I have an older Fedora server so I had to dig around;  I found several useful Howto’s. What worked best for me was the following steps:

From root login:

$ cd /usr/local
$ wget http://nodejs.org/dist/v0.10.25/node-v0.10.25.tar.gz
$ tar zxvf node-v0.10.25.tar.gz
$ cd node-v0.10.25
$ ./configure
$ make
$ make install

Source: Ask Fedora Project

I then put node into default login profile:

$ cd /etc/profile.d
$ vi node.sh
#insert following lines
export PATH=/usr/local/bin:$PATH
export NODE_PATH=/usr/local/lib/node_modules
ZZ

From the root home directory and from my user log in id, I verified that node worked:

$ node -v
v0.10.25

The in my user account, I wrote a hello world style test application:

$ cd $HOME
$ mkdir helloworld
$ cd helloworld
$ vi app.js
// Insert the following files
// I forget which howto website I borrowed this from
var http = require('http');
var server = http.createServer(function(req, res) {
  console.log("web page accessed");
  res.writeHead(200);
  res.end('Hello Http');
});
server.listen(8000);
ZZ
$ node app.js

Note: the app.js is listening on port 8000. To make this work on my server, I needed to go into iptables and open port 8000. I am not going to show how to do that here, but it is easy to do and easy to overlook. It is worth the trouble to get this little app working because you’ll need port 8000 working for the next step.

Once port 8000 is open and the app.js script running, do the following command in a different terminal  window.

From user login:

$ curl -i http://localhost:8000

Output:

HTTP/1.1 200 OK
Date: Thu, 13 Feb 2014 16:27:00 GMT
Connection: keep-alive
Transfer-Encoding: chunked

Hello Http 

This turned out to be harder than I thought. The nodejs website offers Linux Binaries; I tried them and they didn’t work. I assume I did something wrong. Instead, I did the install from source setup.  On my machine, it took about 10 minutes to compile and build. (The make step was longer than I thought).

Restify Module

The node.js community has a large library of packaged modules. I picked the Restify module to build my package upon.  Since I am new to node, I don’t really know what the best choice would be, I just wanted to leverage something that had some good howto articles.

To setup restify, I ran the following steps from my root login:

$ npm install restify -g

Then from my development login, I wrote a barebones test application:

$ cd $HOME
$ mkdir restify
$ cd restify
$ vi app.js
// insert the following lines
// borrowed from stack overflow article:
// http://stackoverflow.com/questions/17589178/why-should-i-use-restify
var restify = require('restify');
var server = restify.createServer();
function respond(req, res, next) {
    res.send('hello ' + req.params.name);
}
server.get('/hello/:name', respond);
server.listen(8000, function() {
    console.log('Listening on port 8000');
});
ZZ
$ node app.js

Like the previous hello world test, this one verifies that basic restify works. I ran “node app.js” in one terminal window and in the other, I ran the following:

$ curl -i http://localhost:8000/hello/jack

Output:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 12
Date: Thu, 13 Feb 2014 17:03:19 GMT
Connection: keep-alive

hello jack 

I make this all look so easy, but along the way I had several gotcha type problems. I originally didn’t have the environment variables setup right. And, my initial installation of restify, I forgot to use the -g option. And for my initial setup, I did a couple of things in my root login that should have been done in my user login, etc. It is worth it to get the basic hello world done before you start.

Reference:  Creating a basic node.js api with restify and save by Dom Udall

My REST Design

My web application edits and reports on some resources stored on my server. I want to grant access to these resource through a REST-ish API. The two key resources are charts and jefiles — it turns out that these are actually text files stored on my server. There is one chart file per year, so in my REST URI  I use the notation: chart/YY. The jefile files are monthly, with 12 months per year, so I picked the notation jefile/YY/MM.  In my REST URIs, MM=00-12 and YY is any two digits representing a year (eg YY==12 implies 2012, YY==98 implies 1998).

So, my design is for the following “GET” operations return data from the server to my web application:

# returns contents of chart file for the year YY, 
# where YY is 13 for 2013
http://localhost:8000/chart/YY 

# returns contents of jefile for the year YY, Month MM
# - where YY is 13 for 2013
# - where MM is 01-12, for a month
http://localhost:8000/jefile/YY/MM  

# returns concatenation of all jefiles for the year YY
# - where YY is 13 for 2013 (used for year to date reports)
http://localhost:8000/jefile/YY

Also, for debugging purposes, I want both plain text and json formatted data returned. I picked the above syntax to represent plain text response. Here’s the syntax for json responses:

http://localhost:8000/chart.json/YY
http://localhost:8000/jefile.json/YY/MM
http://localhost:8000/jefile.json/YY

I have experimented with using MIME types or other header mechanisms to control plain text vs json. I like this method because it lets me debug in any a normal browser; no special REST browser plugins needed to be installed. This approach is also valuable to me because it maintains continuity with my existing, several year old, PHP design approach.

So with this design, here’s the basic restify application.

From the file app.js:

var restify = require('restify');

var server = restify.createServer();
server
  // Allow the use of POST
  .use(restify.fullResponse())
  // Maps req.body to req.params so there is no switching between them
  .use(restify.bodyParser());

server.get('/chart/:YY', getChart);
server.get('/chart.json/:YY', getChart);

server.get('/jefile/:YY', getJefileForYY);
server.get('/jefile.json/:YY', getJefileForYY);

server.get('/jefile/:YY/:MM', getJefile);
server.get('/jefile.json/:YY/:MM', getJefile);
server.put('/jefile/:YY/:MM', putJefile);

server.listen(8000, function() {
    console.log('Listening on port 8000');
});

The server.get() callback functions (eg getJefile() ) all follow a common pattern:

function getJeFile(req, res, next) {
    console.log(params.req.YY);
    console.log(req.route.name);
    ...; 
    res.send(...);
    next();
}

The restify framework’s server.get() function takes the incoming REST request, parses the URI and matches it to the first parameter of the server.get() function,  and runs the callback  function with the request neatly parsed into the object req. Since in REST APIs, the GET method nominally has an empty message body, the only real input are the parameters parsed out of the URL. In my code above :YY and :MM ids are the names of the URI parameters.

These parameters are parsed by restify and stored  in the object params.req. For all of my server functions, I always have params.req.YY as in input. Restify API document covers this, but again, this design pattern is found throughout nodejs code as a way for a chain of functions to all share the same input and output objects.

The callback functions above (eg getJeFile()) generates the content that gets stored into the response object, the 2nd callback parameter res. When the callback function is complete, it calls next(), the 3rd parameter.

So here’s what my 3 server.get() callback functions look like.

From app.js:

getChart = function getChart(req, res, next) {
    console.log(req.route.name);
    var year = req.params.YY;
    // validate year
    // get contents of chart file
    // if I find any errors:  return next( Error object )
    res.send(chartFile);
    return next();
}

getJefile = function getJefile(req, res, next) {
    console.log(req.route.name);
    var year = req.params.YY;
    var month = req.params.MM;
    // validate year, month
    // read contents of jefile file
    // if I find any errors:  return next( Error object )
    res.send(jefileFile);
    return next();
}

getJefileForYY = function getJefileForYY(req, res, next) {
    console.log(req.route.name);
    var year = req.params.YY;
    // validate year
    // get contents of all of the jefile files, concatenate
    // If I find any errors:  return next( Error object )
    res.send(jefileFileForYY);
    return next();
}

Note:  the above code is simplified to better help explain what I am doing.

For the case where my web application wants to write content to the server, I use the REST PUT method. The PUT method writes or overwrites the full contents of a resource. Since I am working with whole files on the web server, PUT is appropriate. POST would be OK, if I was adding blocks of data to an existing file; but I am not.

So to make a PUT work in the restify framework, my server.put() callback function needs to parse and validate the message body, convert it from JSON to a native format then save the contents to a file on the server. Restify makes this pretty easy. Here’s the basics:

From app.js:

putJefile = function putJefile(req, res, next) {
    console.log(req.params);
    console.log(req.route.name);
    var year = req.params.YY;
    var month = req.params.MM;
    // validate year
    // validate requerst body, named jefilejson, is valid
    jefileFile = JSON.pars(req.params.jefilejson)
    // write contents of jefileFile to server, directory YY, file-MM
    res.send(200)
    return next();
}

Note: the message body holds a json object; in my case, the web application names the json object jefilejson. So to access the contents of the message body, you access req.params.jefilejson.

Validating the MM and YY ids

The server.get() routing function’s syntax makes it easy to match roughly correctly formatted URIs, but for me, it didn’t have enough checking power to verify that the YY and MM ids were correct. Server.get() just matches any character between the slashes; it doesn’t check that YY is 2 numeric digits or that MM is 01-12 only with the leading zero required. I had to add my own validation logic in each of my callback functions.

It turns out the code for verifying YY and MM ids was several lines of coded repeated multiple times. Node.js and restify design patterns give you the option of inserting additional callback functions into the server.get() function call. I added validation functions as follows:

From app.js:

server.get('/chart/:YY', validateYY, getChart);
server.get('/chart.json/:YY', validateYY, getChart);

server.get('/jefile/:YY', validateYY, getJefileForYY);
server.get('/jefile.json/:YY', validateYY, getJefileForYY);

server.get('/jefile/:YY/:MM', validateYY, validateMM, getJefile);
server.get('/jefile.json/:YY/:MM', validateYY, validateMM, getJefile);
server.put('/jefile/:YY/:MM', validateYY, validateMM, putJefile);

Now, I liked this because it let me re-factor a bunch of common code out of each of my callback functions. I have seen other node.js code snippets that take advantage of this coding pattern.

Validation Functions and Error Handling.

Within a nodejs or restify program, there’s a common way of handling errors. Since everything is asynchronous and chained together with next() functions, there needs to be a way to break the chain on error conditions. The key technique is to call the next() function with an Error object as a parameter. Let me show how I coded the validateYY() function.

From app.js:

/*
** Validate YY id.
** -- syntax:  2 digits, 00-99
** -- directory nfroot+YY must exist
*/
function validateYY(req, res, next) {
    var ret = 500;
    var year = req.params.YY;
    console.log('validateYY:'+req.route.name);
    var isValidYY = year.match(/^\d\d$/);
    if (!isValidYY) {
        ret =  new Error("The field YY-'"+year+"' is not valid.  YY is a two digit year where YY is 00-99");
        ret.statusCode = 400;
        return next(ret);
    }
    /* Verify that YY exists */
    if (!fs.existsSync(nfroot+year)) {
        ret = new Error("The field YY-'"+year+"' is not valid. The diretory-'"+nfroot+year+"' doesn't exist on server.");
        ret.statusCode = 404;
        return next(ret);
    }
    /* Verify that YY is a directory */
    if (!fs.lstatSync(nfroot+year).isDirectory()) {
        ret = new Error("Server side problem:  The path -'"+nfroot+year+"' is a file, but must be a directory.");
        ret.statusCode = 500;
        return next(ret);
    }
    return next();
}

The key is the Error object. When I first saw code snippets using the Error object, I didn’t really know what’s going on. I Googled it and found there’s a rich design pattern built into node.js around how errors are handled. If you just jump into node.js like me, there’s lots of things you need to learn. Restify just leverages Error, assuming coders already know how to work node.js.

Notice in the code above, I tried really hard to follow best practices for mapping http error codes into my REST API definitions. For the case of  someone trying to access a resource like a particular jefile file within a year (eg ..jefile/YY/MM): If the syntax was wrong, I returned a Bad Format (400) error; if the format of the REST URI was right but the file requested file didn’t exist I returned a Not Found (404) error. Also, I even verified that YY in the path was really a directory on the server; if not, that’s shouldn’t ever happen — I returned a Server Error (500).

The way the function chaining works: if next() is passed an Error object, the chaining stops and a json formated response is generated with Error information. This powerful construct is built into node.js, but if you didn’t know it, you might start inventing it yourself, especially if you come from a PHP background, like me.

Splitting Node applications into multiple files – Module Loading with Require

When I first started my node project, I put everything into one big app.js file. This got too big and clumsy for me. I am used to working on projects where coding is split across multiple source files. The node documentation defines a method for split source code across multiple files…  similar to how multiple modules are handled in web browser applications.

I decided to dedicate a source file to each of my main REST resources. For this writeup, those would be chart.js and jefile.js. I still have a main app.js. The way to link them together is to use the require() functions at the top of each file:

Contents of app.js:

var restify = require('restify');
var chart = require('./chart');
var jefile = require('./jefile');
...
server.get('/chart/:YY', validateYY, chart.getChart);
server.get('/chart.json/:YY', validateYY, chart.getChart);
server.get('/jefile/:YY/:MM',validateYY,validateMM, jefile.getJefile);
server.get('/jefile.json/:YY/:MM',validateYY,validateMM,
             jefile.getJefile);
server.put('/jefile/:YY/:MM',validateYY,validateMM,jefile.putJefile);

Contents of jefile.js:

exports.putJefile = function putJefile(req, res, next) { ... }
exports.getJefile = function getJefile(req, res, next) { ... }

Contents of chart.js:

exports.getChart = function getChart(req, res, next) { ... }

Note a few things: the require() function for restify does not need a path. I installed the restify NPM globally (-g option).  The require() function is only needed in the main file, app.js. The restify routing functions (eg server.get()) references callback functions from the other source files, by prefixing with chart or jefile. And, the source code for those callbacks are written as exports (eg. exports.getJefile = …).

Note how I managed, syntactically, my REST GET API methods for returning plain or JSON responses.  ../chart/YY returns the contents of the chart file for year YY; ../chart.json/YY returns the same file, but in JSON format.  Visually, I would rather see the contents of the chart file in native format, but for web page development, I want all responses in JSON format.  The server.get() callback for both of these cases is getChart().  The way the getChart() function knows to return json or native format is by looking at the req.route.name parameter; that tells me how the getChart() was called.

The way source files are modularized is a pattern is written about in the nodejs documentation, but it turns out there are many more advanced ways of managing modules. This one worked great for me. It also made it easier for me to debug and test each resource without wrecking, accidentally, the others.

Reference: Node API Docs: Modules 

Run Node and Apache both on Port 80

As I get my REST web service using Node working, I need to integrate it into the web service infrastructure already installed on my server.  Port 80 today runs Apache serving  blogs, weather stations,  and a couple of web applications — all intertwined with Apache and I cannot just start over.

So I found a way to get Apache to work with node; I keep node on port 8000 and Apache on port 80 and configure an Apache “ProxyPass” for URLs to the node-based REST service.

In /etc/httpd/conf/httpd:

<VirtualHost 64.53.181.XXX 192.168.100.XXX >
    ServerName mydomain.com
    ...
    ProxyPass /node http://localhost:8000/
    ...
</VirtualHost >

Any URI with mydomain.com/node in it gets redirected to my node service. This is good, but part of the reason for moving to node is that it is supposed to give much improved performance — not that Apache is slow, but because it has years of historic features built into it that take longer to execute.

Well someday, I’ll run only node. But for now, for me, node must coexist and this method works for me.

Conclusions

Working with Javascript on the server side was nice.  For me, the debugging skills that I use for web page development carried over nicely to node development.  Nodejs’s asynchronous design pattern was new to me, but once I caught on, it wasn’t bad.  The way nodejs standardizes error handling is much better than the adhoc approaches that I have been using with PHP.

I found that I missed some of the PHP built in functions.  For example, to access files on the server, nodejs has a very robust File System module.  It behaves differently from PHP, but I was able to figure it out — they are all based on the same underlying C libraries.  I resisted the temptation to use one of the frameworks that help bridge PHP developers into nodejs; they aren’t bad, but they worked against my objective to learn.

Some next steps:  I would like to do some performance comparisons.  Superficially, my REST API re-written in node is faster than the existing PHP implementation.  I’d like to quantify.  Also, I have written server side code, that I ought to be able to use inside the web client applications; that would be a nice thing to clean up.  Also, I’d like to get my node application to do logging at least equal to the logging I get from Apache — restify has some nice built in features for that.

There’s a big library of NPM modules out there. I’d like to learn more about them. This time around, all I really needed was restify. Maybe next time, I’ll try to use more of the features inside of it, or branch out and learn express. Anyway, thanks to the greater nodejs community for helping me get started.

The post REST web service using Node, was originally written in PHP appeared first on JackKozik.com.

For this round of coding, I am focusing on the $.ajax() method. In my present design, my single page web application makes REST calls for many of the UI menu items. For example, a click on the FILE->LOAD menu item triggers a function call to code that retrieves a file from my server. The basic pattern is like this:

// Start spinner
// start logging timer
$.ajax({"url":RestURI,
 "type":"GET",
 "dataType":"json",
 success: function(data) {
 // Do success stuff (parse, format and display)
 // stop logging timer, do logging
 // stop spinnger
 }, /* end success: */

 error: function (req, stat, err) {
 // Do error stuff
 // stop logging timer, do logging
 // stop spinner
 } /* end error: */
});

I have more than 7 code blocks that follow this pattern. Since the success/error/complete callback functions have been deprecated and I need to touch the code anyways, I thought I’d use the newish $.ajax() global events handlers  to clean up my code. The event handlers seem to be a useful place to put common pieces of code that really shouldn’t have been so liberally cut-and-pasted when I wrote the original code.

For each of my ajax code blocks, I put a generous amount of logging in. Maybe this logging should only be needed when writing/debugging the code, but for me, since I spend so little dedicated time on this application, I wanted to keep verbose logging on always to make it real easy for me to debug.

$.ajax logging using Ajax Global Events

The following new block of code is doing my $.ajax logging using Ajax Global Events.

$(document).ajaxSend(function(evt, xhr, settings) {
 console.log(settings.type+" "+settings.url+" Sent");
 start = new Date().getTime();
 // Other logging
});
$(document).ajaxSuccess(function(evt, xhr, settings) {
 console.log(settings.type+" "+settings.url+" Success");
 // Other logging
});
$(document).ajaxError(function(evt, xhr, settings, exc) {
 console.log( settings.type+" "+settings.url+" Failed. "
 +xhr.status+"-"+xhr.statusText);
 // Other logging
});
$(document).ajaxComplete(function(evt, xhr, settings) {
 console.log(settings.type+" "+settings.url+" Complete");
 end = new Date().getTime();
 diff = end - start;
 // Other logging
});

As you can see, the ajaxSend/ajaxSuccess/ajaxError/ajaxComplete events are fired in sequence at the $.ajax() function executes and after the  .done(), .fail() and .compete() callbacks are executed.

The “Other logging” comment represents 2 or 3 lines of code where I put logging information into a user visible menu item (REPORTS->LOG) where I can see even more details without having to open the console window. For me, this effort is a nice clean out some of the logging stuff, to make the application logic a little more visible;  this clears up a bunch of clutter for me.

New-ish .done/.fail/.always Callbacks

Therefore, my $.ajax() code blocks are straighten out to follow the new done/fail/always callbacks. Here’s an example new $.ajax() code block:

// Start spinner
$.ajax({url:RestURI,
 type:"GET",
 dataType:"json"})
 .done( function(data, textStatus, jqXHR) {
 // Do success stuff
 }) /* end done: */

 .fail( function (jqXHR, textStatus, err) {
 // Do error stuff
 }) /* end fail */

 .always( function() {
 // stop spinner
 }); /* End always */

Some things to note: I still put the start/stop spinner function calls inline. I may move this to the global even handlers, but not yet.

Deferred Objects

Also, the done/fail/always call backs follow the new Deferred Object model. This will then let me setup some promise objects to let me address some of the async race conditions I have in my application.

For example, I have a case where I can run FILE->SAVE and then run REPORT->General and the report will produce results before the save was completed. I know how to fix this, but I was looking to use my new ajax code blocks architecture to get some practice with promise objects instead… for next time.

The post $.ajax logging using Ajax Global Events. Re-factoring Single Page Web Application appeared first on JackKozik.com.

The blog posting took a crazy long time to load. I am used to WordPress blog pages being a little heavy and but this was too slow.

I had recently learned about the WebPageTest.org tool, and decided to use it to troubleshoot my issue. Other bloggers point to this website for workingSlow Website Load Time issuess. Here’s what the tool’s waterfall summary page  showed me:

The chart had lots of red lines: these are lines that reflect 404 error timeouts. I was surprised; the posting didn’t have any links to external content (that I knew of!). I clicked on the waterfall thumbnail and saw the following:

The 404s are from style.css, normalize.css, main.css, and jquery-ui — huh? These are links in my code snippet!

My blog postings showed the before/after of my <head> section of my normalized web page. Here’s the after snippet:

So do web browsers resolve and fetch URLs embedded in <pre> sections? Really? (sorry to be ignorant about this, but I really didn’t think so). Yes a quick search of stackoverflow and I find that this questions has been asked and answered. When you have a <pre> block, you need to escape the < and > characters (&lt; and &gt;). Stackoverflow reference

So, I manually edited my code snippets to escape the angle brackets, and everything loaded much more quickly. The browser no longer tried to resolve the URLs.

Here’s the new WebPageTest.org thumbnail (no red lines!)

Oh, and while I was learning the WebPageTest.org tool, I found a bunch of other problems, which were much more obvious and easy to fix.

The post Code Snippets Causing Slow Website Load Time appeared first on JackKozik.com.