So I can’t take really any credit for this blog post as the original work was all done by William Lam. I have my own homelab and also maintain a few labs at work that are hidden off in their own networks. This little trick comes in real handy. Mainly because I have quite a few environments to log into and it makes it simple when I don’t need to remember which domain they are under. The location of the file has changed under 6.5 and 6.7 so I just figured I would update his original post with the location in the new versions.
The file in question is unpentry.jsp that needs to be modified. In version 6.0 the file is located at /usr/lib/vmware-sso/vmware-sts/webapps/websso/WEB-INF/views/unpentry.jsp. The new file is located at /usr/lib/vmware-sso/vmware-sts/webapps/ROOT/WEB-INF/views/unpentry.jsp.
When you use vi to open the file on the VCSA (assuming that’s what pretty much everyone is using these days) the area to be modified is the same. The lines should look like the following:
Obviously, the actual login info will match your environment. Once those are modified and saved, you will see the wonderful screen when pulling up your environment:
You may need to click on the fields for the Login button to light up, but hey….no more typing username and passwords in!
Thanks again to William for the info. Now if we could just get a skin creator/ theme engine for the HTML5 client………
Recovering from dual hernia surgery and changing job roles…….it’s me and I’m back. Moving back into the Blueprint, we are working on Objective 2.1 – Create and Manage Logical Switches. We will be covering the following points in this blog post.
Create and Delete Logical Switches
Assign and configure IP addresses
Connect a Logical Switch to an NSX edge
Deploy services on a Logical Switch
Connect/Disconnect virtual machines to/from a Logical Switch
Test Logical Switch connectivity
First it would probably be appropriate to make sure that we know what a logical switch can do. Just like its physical counterpart, an NSX switch can create a logical broadcast domain and segment. This keeps broadcasts from one switch from spilling over to another and saving network bandwidth. Feasibly you can argue that the network bandwidth is a bit more precious than real network bandwidth because it requires not only real network bandwidth but also requires processing on the side of the hosts (whereas normal network bandwidth would be processed by the ASIC on the physical network switch).
A logical switch is mapped to a unique VXLAN which then encapsulates the traffic and carries it over the physical network medium. The NSX controllers are the main center where all the logical switches are managed.
In order to add a logical switch, you must obviously have all the needed components setup and installed (NSX manager, controllers, etc) I am guessing you have already done that.
In the vSphere Web Client, navigate to Home > Networking & Security > Logical Switches.
If your environment has more than one NSX Manager, you will need to select the one you wish to create the switch on, and if you are creating a Universal Logical Switch, you will need to select the primary NSX Manager.
Click on the green ‘+’ symbol.
Give it a name and optional description
Select the transport zone where you wish this logical switch to reside. If you select a Universal Transport Zone, it will create a Universal Logical Switch.
You can click Enable IP Discovery if you wish to enable ARP suppression. This setting is enabled by default. This setting will minimize ARP flooding on this segment.
You can click Enable MAC learning if you have VMs that have multiple MAC addresses or Virtual NICs that are trunking VLANs.
The next point, assign and configure IP addresses, is a bit confusing. There is no IP address you can “assign” to just the logical switch. There is no interface on the switch itself. What I am guessing they meant to say here was that you should be familiar with adding an Edge Gateway interface to a switch, and adding a VM to the switch. Both of these would in a roundabout way assign and configure a subnet or IP address to a logical switch. That’s the only thing I can think of anyways.
The next bullet point is, connecting a logical switch to an NSX Edge. This is done quickly and easily.
While you are in the Logical Switches section (Home > Networking & Security > Logical Switches), you would then click on the switch you want to add the Edge device to.
Next, click the Connect an Edge icon.
Select the Edge device that you wish to connect to the switch.
Select the interface that you want to use.
Type a name for the interface
Select whether the link will be internal or uplink
Select the connectivity status. (Connected or not)
If the NSX Edge you are connecting has Manual HA Configuration selected, you will need to input both management IP addresses in CIDR format.
Optionally, edit the MTU
Click Next and then Finish
The next bullet point covers deploying services on a logical switch. This is accomplished easily by:
Click on Networking & Security and then click on Logical Switches.
Select the logical switch you wish to deploy services on.
Click on the Add Service Profile Icon.
Select the service and service profile that you wish to apply.
There is an important caveat here, the icon will not show up unless you have already installed the third party virtual appliance in your environment. Otherwise your installation will look like mine and not have that icon.
The next bullet point, Connecting and Disconnecting VMs from a Logical Switch is also simply done.
While in the Logical Switch section (kind of a theme here huh?), right click on the switch you wish to add the VM to.
You have the option to Add or Remove VMs from that switch – as shown here in the pic
The final point, testing connectivity, can be done numerous ways. The simplest way would just be to test a ping from one VM to another. This could be done on pretty much any VM with an OS on it. You can even test connectivity between switches (provided there is some sort of routing setup between them. If you only had one VM on that segment (switch) but you had a Edge on it as well, you could pin the Edge interface from the VM as well. There are many ways to test connectivity. And with that, this post draws to a close. I will be back soon with the next Objective Point 2.2 Configure and Manage Layer 2 Bridging.
It has been a remarkably long time since my last post, and I apologize for that. Things got in the way…Such as my own laziness, job, laziness. You get the idea.
This blog post was conceived because of the lack of posts out there for this. Granted I may just be dense but it took me a while and some help to get this working and I used a previous blow post from another author for this. This post here http://blog.bertello.org/2015/07/building-a-basic-3-tier-application-for-your-home-lab/ was used as a template but there were a number of problems and things that were left out that caused me issues. So, I took it upon myself to correct those small things and repost it. In full disclosure, I did try to reach out to the blog author, but have not heard back from him yet.
To start out with a bit about my enviro. I created a couple of VMs using my home lab setup of vSphere 6.5. I don’t have anything fancy in it right now, especially since NSX doesn’t run on 6.5 currently. I started the VMs out with what vSphere automatically provisioned for the VMs, 1 vCPU, 2Gb of RAM, and 16GB HD. This can be reduced of course since I am just using CentOS 6.8 minimal install CD and don’t believe there will be a lot of traffic that they need to handle. I ran through the graphical setup and setup a hostname and IP address on each of the machines. The goal of course is to have these machines eventually be on separate network tiers to test out all the features available to us in NSX, such as micro-segmentation. (of course this is once NSX is supported on 6.5 vSphere)
I am using CentOS 6.8 (which is the latest release on 6.x as of this writing) and the main reason why is that I am more familiar with 6.x than 7. Also Linux is free and easy to deploy and doesn’t take much in the way of resources, providing a perfect OS to use. The first thing we need to do is disable the firewall. This IS a lab environment so I am not too worried about hackers etc., and I will be adding NSX firewalls on them later. To accomplish this, type the following:
service iptables save
service iptables stop
chkconfig iptables off
You will do this for both machines. We will concentrate on the database server first. This is only going to be a 2 tier app. We will have a Database server and a Web/PHP/Wordpress server. You can add more however you want to but this is a good start. Perhaps for the third you could add proxy like the blog post above. Personally, I was just going to put the client machine on it to access the first two. But it is all up to you – it’s your world, and if you want a happy little tree in there, you put one in there. J
Database Server Config
We are going to use MySQL like the original blog.
yum install -y mysql mysql-server mysql-devel
The above line will install all the needed pieces of SQL that we will need. We now need to start the service, set it to run at start up, and go through the small setup of creating a admin password and deciding whether we want a default database in addition to the one we create and if we want to allow anonymous users and remote root login.
service mysqld start
chkconfig mysqld on
Also another thing I should note is that it is much easier to copy and paste my commands. To do this I would recommend using puTTY. We are now going to create our database and set permissions for it.
mysql -u root -p
SELECT User, Host, Password FROM mysql.user;
CREATE DATABASE wordpress;
CREATE USER wp_svc@localhost;
CREATE USER wp_svc@’%’;
SET PASSWORD FOR wp_svc@localhost=PASSWORD(“Password123”);
GRANT ALL PRIVILEGES ON wordpress.* TO wp_svc@localhost IDENTIFIED BY ‘Password123’;
GRANT ALL PRIVILEGES ON wordpress.* TO ‘wp_svc’@’%’ IDENTIFIED BY ‘Password123’;
You can change the above to whatever parameters you wish, just write them down as you will need them later. I also bound MySQL to the IP address you can do that at /etc/my.cnf if you wish. The code is below.
Obviously, you would change the IP address to the one you are using. And that’s it for the DB.
First thing we need to do on this machine is disable the firewall again. We also need to disable SELINUX since if we don’t, our packets will never leave this machine (something I struggled with and finally got the help of my good friend Roger H. in order to figure out. Shameless plug for him at his blog here http://www.rhes-tech.com/ – I highly recommend you check him out as he is a brain when it comes to Linux things. So here is the code we need:
service iptables save
service iptables stop
chkconfig iptables off
In order to disable SELINUX from making our life horrible, we are going to set it to Permissive mode. If we fully disable it, it could scream at us. Therefore, use your favorite text editor and edit /etc/sysconfig/selinux file and you want to change the SELINUXTYPE=targeted. It will look like this :
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing – SELinux security policy is enforced.
# permissive – SELinux prints warnings instead of enforcing.
# disabled – SELinux is fully disabled.
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted – Only targeted network daemons are protected.
# strict – Full SELinux protection.
# SETLOCALDEFS= Check local definition changes
Next we are going to install a ton of stuff.
yum install -y httpd
chkconfig –levels 235 httpd on
The above installs Apache web server and starts it at machine start up. Next we need to install PHP as this is what WordPress requires to run. We will also install the supporting modules.
Next we will download the latest version of WordPress (as of this scribbling 4.7) and we will then need to unzip it and then copy it over to the webserver www home directory. Then we will need to add the config to point back to the DB server.
Again, using your favorite text editor open the wp-config.php file and change it like below. If you chose different values for your database name and username/password you will need to use that info now.
// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
/** MySQL database username */
/** MySQL database password */
/** MySQL hostname */
/** Database Charset to use in creating database tables. */
/** The Database Collate type. Don’t change this if in doubt. */
Once this is done you can go to your website to finish the WordPress install. The address should look something like this. You can use the FQDN or IP address.