Old frankenpix information

Just posted here to preserve it for posterity.

In the old days, I would make Frankenpix boxes.  These would be basically identical to a PIX520 or LocalDirector 430/416.  They were Cisco PIX/LocalDirector clones, using the following hardware, and they worked great:

 

MOTHERBOARD:
Intel Motherboard SE440BX-2 $ 100

NETWORK INTERFACE:
Intel Pro100/B 10/100 NIC PRO100/B $ 40
– OR –
Osicom 4 Ethernet Port PCI OLN-2404TX $ 900

ISA FLASH CARD:
16MB ISA Flash Card (PEP) CISCO – $ 700
– OR –
4MB ISA Flash Card (??) ?? $ –?

The difficult part in all of this was acquiring the ISA Flash card, which usually you had to canabilize out of a dead PIX.

 

 

Posted in Uncategorized | Tagged , | Leave a comment

Get self-signed certificates to work with Cloud Foundry Integration for Eclipse Plug-In

featured-pcfIf your like myself you use self-signed certificates in your lab environment, as its quick and easy.  In my Pivotal Cloud Foundry lab I have generated a self-signed certificate in the Elastic Runtime configuration.  When you have a self-signed certificate you add --skip-ssl-validation to your cf api and cf login commands.

With the latest builds of the Cloud Foundry Integration for Eclipse Plug-In, self-signed certificates have an issue.  They will generate an error with something to the effect of:

Caused by: sun.security.validator.ValidatorException: 
    PKIX path building failed: 
    sun.security.provider.certpath.SunCertPathBuilderException: 
    unable to find valid certification path to requested target

 

It will ask you if you wish to ignore this, but regardless the integration will fail, and it won’t be able to validate your credentials, and so you will have no Cloud Foundry integration.

I really like the Cloud Foundry integration in Eclipse so I set off on a way to figure out how to make it work.  Originally I tried an older version of the plug-in, version 1.7.3, which appeared to work.  I was using this with PCF 1.4.0.0 which has just been released.  I removed an application however, and when it did, I believe it removed my apps_manager application which exists in the system org.  I know this sounds weird, because 1) the plug-in should not be removing the apps_manager service under any circumstances, 2) even if it wanted to, my credentials I used in Spring Tool Suite did not have the authority to remove an app from the system org.  I did not spend a lot of time looking into this, I just noticed that I removed an application, and all the sudden my developer console was gone.  (Developer Console is now known as Apps Manager).

To get the integration to work you need to add the self-signed certificate from your PCF to your Java keystore.  Its important to understand which version of Java your running, you may have several versions of Java installed.  Typically the version that is being used is defined by $JAVA_HOME, but you’ll want to verify with STS/Eclipse which version its using or maybe add the certificate to all your versions.

I use a Mac, and typically the original Java installed by Apple is in /System/Library/Java/JavaVirtualMachines.  For example my system has like so:

nettles:~ bfeeny$ ls /System/Library/Java/JavaVirtualMachines/
1.6.0.jdk

This however is not the version I am using.  When you install later versions, from Oracle for example, they are installed in /Library/Java/JavaVirtualMachines:

nettles:~ bfeeny$ ls /Library/Java/JavaVirtualMachines/
jdk1.7.0_76.jdk

This is the one I am using, and it can be further verified by looking at my $JAVA_HOME:

nettles:~ bfeeny$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.7.0_76.jdk/Contents/Home

Java stores its trusted certificates in a keystore, which on my system is located at

$JAVA_HOME/jre/lib/security/cacerts

The first thing to do is extract the self-signed certificate from your Cloud Foundry, an easy way to do this is using openssl like so:

nettles:~ bfeeny$ openssl s_client -connect api.cf.lab.local:443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/public.crt
depth=0 C = US, O = Pivotal, CN = *.cf.lab.local

verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, O = Pivotal, CN = *.cf.lab.local
verify return:1
DONE

We can verify its there:

nettles:~ bfeeny$ more /tmp/public.crt
-----BEGIN CERTIFICATE-----
MIIDHDCCAgSgAwIBAgIVAP1HgDzBrzGSFY9lUTvpeOl0fpxPMA0GCSqGSIb3DQEB
BQUAMDgxCzAJBgNVBAYTAlVTMRAwDgYDVQQKDAdQaXZvdGFsMRcwFQYDVQQDA4qa
LmNmLmxhYi5sb2NhbDAeFw0xNTA0MTUwMTQ0NTFaFw0xNzA0MTQwMTQ0NTFMDgxx
CzAJBgNVBAYTAlVTMRAwDgYDVQQKDAdQaXZvdGFsMRcwFQYDVQQDDA4qLmNmLmxh
Yi5sb2NhbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMPL/JZ2Ehqt
kLzJn2mlS0XTURSdeaZvaSqdwMvm9Fg7UauC8pI5mAAxg/PEmlY5NXbXuOMrO6WK
ZLy3mQbCdhgw5JWc/qKJV9SQHP0Npn27mLjhiydo08kXv2IzKVwm5YfPkEw5u5SE
GgPzSqQUIiziLuhpMr7ztir4OICvmj8u0LebpKXyO3y+deeibYNLislu/lrr9ZKD
7ADgiM4tZH/c21HVf6cFz9eBbAoCqXY/Q+nZeRb2o4rxmDitojqf30WK9i+Qhqeu
18QPX/EFRIhFrBCYs6YloUDBrPtVvZrOX7kp5zxBGC89+XmMmLUzFzkYpGld9Mfg
l+En+ZQen4cCAwEAAaMdMBswGQYDVR0RBBIwEIIOKi5jZi5sYWIubG9jYWwwDQYJ
KoZIhvcNAQEFBQADggEBAJ+B6P2zkpWp8F7L5N/gRWwM2sumpXUJNwQU3m9ylM5U
yJOgifrk3f410LWsoifbs2Rd7re8NOV7Sud15gjCGI/Zw8mFJElSqd0HrPw0WFB/

v55p/cNKgZJQ4bcpZ0Jp7Y7P7FzLcp76wAacljnbYGkXdxCsrtpUd/VxtNzOeIBP
dbQQxW6Ph9cvSx/w28AaoU9DeoqZvOTnQu2Rltfn6lBPijWQWTEXltiS1WPCyyd+
2Gnl+acnNerspdnHn1lte4ydDR+uq2hYnCJSrlMXaR5TAp3dpwMxtSHA71zkVS61
VRU/vLLtyz3JzAmhGepZ6m2vt2vMNPNGKxVS0c/odNI=
-----END CERTIFICATE-----

Of course, if you have access to the Ops Manager, you can just go into the Elastic Runtime tile and look at the IPs and Ports and grab the certificate from there, that is where you created it in the first place.  There are two certificates listed, the first one is the public one, which is the one you want, and the second is the private.  Whether you use openssl or just cut and paste it, the result should be the same.

Ops_Manager_and_bfeeny_—_root_4b620d1c-cad4-4395-a85a-21f2e357fb43___var_vcap_bosh_log_—_bash_—_165×27_and_pcf-docs-1_4__page_6_of_480_

 

 

 

 

 

Now you simply have to import the certificate into the Java keystore:

nettles:~ bfeeny$ sudo keytool -import -alias api.cf.lab.local -keystore $JAVA_HOME/jre/lib/security/cacerts -file /tmp/public.crt
Password: <enter your admin password here>
Enter keystore password:  <default password is changeit>
Owner: CN=*.cf.lab.local, O=Pivotal, C=US
Issuer: CN=*.cf.lab.local, O=Pivotal, C=US
Serial number: fd47803cc1af3192158f65513be978e9747e9c4f
Valid from: Tue Apr 14 21:44:51 EDT 2015 until: Thu Apr 13 21:44:51 EDT 2017
Certificate fingerprints:
MD5:  C4:DA:C3:02:B4:25:FC:A9:1E:A1:FB:3A:E0:F7:B5:AD
SHA1: EB:A4:1E:A5:EA:D4:BE:7A:A3:CD:9B:D4:4D:BF:1F:1C:DD:97:52:ED
SHA256: 12:7C:1E:69:32:D4:28:FE:6B:EE:2A:DE:91:FB:76:5E:A6:1F:29:DA:15:A5:4C:21:E8:4C:73
83:BE:0A:78:77
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
 DNSName: *.cf.lab.local
]
Trust this certificate? [no]:  yes
Certificate was added to keystore

After this is done, simply restart your Eclipse or Spring Tool Suite application, and it should now allow you to add a Cloud Foundry instance with no issue.  If you have already added an instance, simply delete it and re-add it.  Fill out your credentials, and all should validate properly.

Update: I passed this onto Pivotal and they have added it to their Knowledge Base!

Posted in Cloud Foundry, Pivotal | Tagged , , , | Leave a comment

My thoughts on the Intel NUC5i3RYK as a vSphere host

IMG_1529 copyRecently I have been expanding my lab, which included two vSphere hosts.  At the time, my hosts which each had 16GB, were substantial lab nodes and their Nehalem architecture was on top.  Now of days they are modest at best.  I expanded them out each with 32GB (previously they had 16GB), but still needed a few more cores and memory in order to deploy Pivotal Cloud Foundry.  My thought was to add a host that would serve to run vCenter Server Appliance, as well as be able to offer a bit more cores and memory to the available resource pool.

I quickly started looking at the Intel NUC line of computers.  After looking at the best value for my application, I settled on the NUC5i3RYK which has the following attractive qualities:

I quickly added the following components to my base NUC5i3RYK

16GB is sufficient for a vSphere environment.  My personal rule of thumb is 8GB per core, which works out nicely with the 2C provided by the NUC.  I would of course much prefer a 32GB option, and of course 4C would be eve better.  The Intel i3-5010 is said to support 16GB, but Intelligent Memory has figured out a way of stacking chips to allow it to see 32GB.  This however is not a cheap solution at about $700 for 32GB!

The transcend 128GB M.2 SSD is very nice.  Its amazing what you can fit inside of a little NUC!  Why have an SSD in a vSphere lab environment?  Personally I like to use it for the host scratch space, Host Cache files, and VM swap files.  This alone is worth it to add a relatively cheap SSD into your vSphere hosts. Speeds things up very nicely and cuts down on the amount of iSCSI traffic.  I also chose to park my vCenter Server Appliance on the SSD as well……why not, there is plenty of room.

The Kingston Data Traveler Micro is an awesome device that looks like it was built just for the NUC!  Its only USB 2.0 but that is sufficient.  ESXi fits nicely into 8GB.

Does it run vCenter Server Appliance well?

Yes!  It runs VCSA just great.  Its fast, responsive and all is well.  I think these are perfect hosts to add for this function.  Many people have a few ESXi hosts, like myself.  But where do you put vCenter?  Of course you can run it on both and link them, or you can vMotion it around, but I prefer to just have a stand alone host.  I also prefer to not run Windows, so rather than installing Windows on the NUC’s bare metal and then installing vCenter on it, I chose to install ESXi 5.5 and then just install VCSA on top of that.

What could be improved?

The NUC5i3RYK does not have vPro technology in it which allows for VNC based KVM remote control.  There are NUCs that have this, and I am sure more to come, such as the NUC Kit DC53427HYE.  But of course these are more expensive.  I just really like to have some sort of remote KVM in my vSphere hosts.

The NUCs are limited to 16GB and 2C.  There are currently no NUCs that support more than 16GB (without something ridiculously expensive like the aforementioned Intelligent Memory solution), nor more than 2C.  This is sufficient for the price point, but its nice to have quad core and 32 GB, so you just get extra density.   At the price however (< $300 for a NUC5i3RYK), its hard to be too critical of this point.

The NUCs have only a single 10/100/1000 port, and no way to expand beyond this.  This is what really relegates the NUC to tasks like vCenter vs. running more of the serious VM’s I need in my lab.  If I can’t have a dedicated port for the storage network, the speeds wills suffer.  Of course, I just make a trunk and the NUC is able to communicate on its single physical port using multiple vKernel’s for management and storage.  I like to have multiple physical ports to run iSCSI on however, simply because I find storage to be the bottleneck in most labs and real networks.  I like to be able to run 2x1GB for my iSCSI back to my Synology DS-1010.  Obviously the NUC is limited to at best communicating at 1GB.

How to run vSphere on the NUC5i3RYK?

Everything you need to know was already written very well by Florian Grehl at Virten.net.  You can find his article on How to Install ESXi on 5th Gen Intel NUC.

Final Thoughts

I will buy a NUC again. In fact, I hope to see the product evolve to at least 2 NIC ports, vPro on more models, more memory.  If that happens I may replace my entire lab with these cool little devices.  They run extremely efficient, take up hardly any room and they are dead quiet.  With a cheap investment I was able to expand my lab and not have vCenter take up resources on my key ESXi hosts.  I did reduce the memory of VCSA to just 4GB, which is adequate for a small deployment, this leaves at least 10GB free for vSphere to consume.

 

 

Posted in Intel | Tagged , , | Leave a comment

Properly shutting down and firing back up Pivotal Cloud Foundry

featured-pcfBecause my Pivotal Cloud Foundry lab runs on my modest vSphere environment, every now an then I need to power something down, and I don’t always have the resources to vMotion everything to the remaining servers.  So I needed a method to be able to power down the PCF lab and bring it back up.  Pivotal tech support responded with these recommended instructions:

Normally, it is not necessary to power off PCF because it is providing continuous cloud service. However, if you have to power off the system or some VMs, here are the tested steps.

1) follow the backup procedures outlined at [1] to backup databases and NFS servers, this is for disaster recovery purpose.
2) confirm vSphere HA won’t automatically try to bring back VMs you shut down.
3) shutdown Ops Manager Director VM first, because it detects offline VMs and recreates them automatically.
4) shutdown Cloud Controller VM the next, this action will terminate any futher Cloud Foundry operation.
5) shutdown other VMs.
6) those VMs have VMtools installed, so you can use vSphere “Shut Down Guest” to shutdown VMs gracefully.

When you need to bring those VMs back, just follow the reverse steps above.
1) power on VMs prior to Cloud Controller and Ops Manager Director
2) power Cloud Controller
3) Ops Manager Director
CLI help for details.

Posted in Cloud Foundry, Pivotal | Tagged | Leave a comment

Enabling self service user and org creation in Pivotal Cloud Foundry

featured-pcfPivotal Cloud Foundry has a web page where users can goto and login and manage their environment.  Depending on the privileges assigned to the user this may mean the ability to invite other users, create orgs, create spaces, manage apps, etc.

PCF has a self-service ability to allow users to create their own accounts.  By default this it turned off.

For instance, my PCF domain is cf.lab.local.  I can access the user portal (Formerly referred to as the developer console or just console, but now referred to as apps_manager) at: https://login.cf.lab.local

Pivotal

The link shows to Create Account.  Clicking on it will give the following 403 Forbidden error:

Pivotal_CF

To allow for users to create accounts via self-service, you must set the environment variable ENABLE_NON_ADMIN_USER_MANAGEMENT, and additionally so that they can have their own org, you should enable ENABLE_NON_ADMIN_ORG_CREATION.

From a terminal window, run cf api URL and target your Apps Manager URL. For example:

nettles:~ bfeeny$ cf api api.cf.lab.local --skip-ssl-validation

Setting api endpoint to api.cf.lab.local...
OK

API endpoint:   https://api.cf.lab.local (API version: 2.23.0)   
Not logged in. Use 'cf login' to log in.

Run cf login and provide your UAA Administrator user credentials:

nettles:~ bfeeny$ cf login
API endpoint: https://api.cf.lab.local

Email> admin

Password> 
Authenticating...
OK

Select the system org and the console space:

Targeted org system

Select a space (or press enter to skip):
1. apps_manager
2. app-usage-service
3. autoscaling
4. notifications-with-ui

Space> 1
Targeted space apps_manager

API endpoint:   https://api.cf.lab.local (API version: 2.23.0)   
User:           admin   
Org:            system   
Space:          apps_manager   

Set the ENABLE_NON_ADMIN_ORG_CREATION environment variable to true:

nettles:~ bfeeny$ cf set-env apps_manager ENABLE_NON_ADMIN_USER_MANAGEMENT true
Setting env variable 'ENABLE_NON_ADMIN_USER_MANAGEMENT' to 'true' for app apps_manager in org system / space apps_manager as admin...
OK
TIP: Use 'cf restage' to ensure your env variable changes take effect

Set the ENABLE_NON_ADMIN_ORG_CREATION environment variable to true:

nettles:~ bfeeny$ cf set-env apps_manager ENABLE_NON_ADMIN_ORG_CREATION true
Setting env variable 'ENABLE_NON_ADMIN_ORG_CREATION' to 'true' for app apps_manager in org system / space apps_manager as admin...

OK
TIP: Use 'cf restage' to ensure your env variable changes take effect

Even though it says to run cf restage we can just do a cf restart:

nettles:~ bfeeny$ cf restart apps_manager
Stopping app apps_manager in org system / space apps_manager as admin...
OK

Starting app apps_manager in org system / space apps_manager as admin...

0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running

App started

OK

App apps_manager was started using this command `bundle exec rake server:start_command --trace`

Showing health and status for app apps_manager in org system / space apps_manager as admin...
OK

requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: console.cf.lab.local
last uploaded: Fri Apr 17 00:21:01 UTC 2015

     state     since                    cpu    memory         disk           details   
#0   running   2015-04-16 10:38:25 PM   0.0%   209.3M of 1G   285.1M of 1G

Now that this environment variable is properly set we can goto the login page again:

Pivotal

And this time when we click Create Account we the page we would expect:

Pivotal_CF

We will add a user and click send and are given a positive result:

Pivotal_CF_and_bfeeny_—_tempest_pivotal-ops-manager____—_bash_—_198×47

And email should arrive which looks like below:

Inbox_—_Harvard_FAS_IMAP__75_messages_

Click on Verify your email address and you will be sent to a page to enter your password:

Pivotal_CF_and_Inbox_—_Harvard_FAS_IMAP__75_messages_

 

Once this is done, you now are asked to create an Org:

Pivotal_CF

Now finally you have access to your own version of Apps Manager, and can have an environment of your own:

Pivotal_CF_and_Inbox_—_Harvard_FAS_IMAP__75_messages_

Posted in Cloud Foundry, Pivotal, Uncategorized | Tagged | Leave a comment