Category Archives: Network Infrastructure

Network Infrastructure

Aerohive Status Color Codes

May 15, 2013 – 6:01 am

Ever wonder what those color codes on on all your devices mean while they’re booting up? In the IT industry we went from having beep tones and green lights to now having all kinds of methods including touch screens on printers that are as nice as my iPhone practically, computers with touch screens that indicate POST status and of course LEDs that change colors. The LEDs that change colors can be extra special, because we assume yellow is bad, green is good, blue is good and red is really bad. Aerohive uses a different color scheme, which can be a little confusing at first. So what do their LEDs mean? Here goes:

small payday loans

  • Blue: The access point is booting
  • Green: The access point has a valid IP address over the Ethernet interface and has a valid connection to HiveManager
  • Yellow: The access point has an IP address over the Ethernet interface but is not yet connected to HiveManager
  • White: The access point is connected to HiveManager and is in normal operating mode. All configurations, updates are applied. This should be the normal state of the device.
  • Purple: The access point’s HiveOS has a software image that is in the process of being update.
Permalink | Comments Off
Active Directory Mac OS X Mac OS X Server Mac Security Network Infrastructure Ubuntu Unix VMware Windows Server Windows XP Xsan

List All DNS Records For A Domain

May 8, 2013 – 6:00 am

Sometimes you want to move a domain but you don’t have a copy of the zone file in order to recreate records. The easy way to do this is to grab a zone transfer. To do so, dig is your friend:

dig -tAXFR mycompany.com

Sometimes though (and actually more often than not) a zone transfer is disabled. In that case you’ll need to dig the domain a bit differently. I like to use +nocmd, query for any and list the results (+answer):

dig +nocmd krypted.com any +answer

Which results in the following:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39183
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;krypted.com. IN ANY

;; ANSWER SECTION:
krypted.com. 1262 IN A 97.74.215.39
krypted.com. 3600 IN MX 0 smtp.secureserver.net.
krypted.com. 3600 IN MX 10 mailstore1.secureserver.net.
krypted.com. 3600 IN NS ns25.domaincontrol.com.
krypted.com. 3600 IN NS ns26.domaincontrol.com.
krypted.com. 3600 IN SOA ns25.domaincontrol.com. dns.jomax.net. 2010010400 28800 7200 604800 3600

;; Query time: 127 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Tue May 7 22:31:15 2013
;; MSG SIZE rcvd: 207

The above shows the naked domain name entry (yes, I still giggle every time I write the word naked so it’s ok if you giggled when you read it), all of the mail (which btw I don’t actually use that mail so please don’t try and send any at this time) and the ns servers. Now, the serial and refresh information isn’t included in this output. Actually, it is but it might not make sense, so we’ll just add the +multiline option which will make this look strangely like a zone file:

dig +nocmd krypted.com any +multiline +answer

Notice the serial, refresh, retry, expire and minimum options are now listed in a much more fashionable way:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10965
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;krypted.com. IN ANY

;; ANSWER SECTION:
krypted.com. 3225 IN A 97.74.215.39
krypted.com. 3225 IN MX 0 smtp.secureserver.net.
krypted.com. 3225 IN MX 10 mailstore1.secureserver.net.
krypted.com. 3225 IN NS ns25.domaincontrol.com.
krypted.com. 3225 IN NS ns26.domaincontrol.com.
krypted.com. 3225 IN SOA ns25.domaincontrol.com. dns.jomax.net. (
2010010400 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
3600 ; minimum (1 hour)
)

;; Query time: 22 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Tue May 7 22:32:20 2013
;; MSG SIZE rcvd: 207

And there ya’ go. You’ve basically done a zone transfer on a box, even though zone transfers are disabled. Silly DNS admins, disabling zone transfers and all that… Yes, I disable zone transfers on most of my DNS boxen as well, or at least only allow them for specific IPs… ;)

Tags , , , , , , , , , | Permalink | Comments Off
Network Infrastructure Ubuntu Unix VMware

Using the XenSource Command Line Interface

May 6, 2013 – 6:00 am

XenSource has some pretty good GUI tools. There’s XenCenter and the xsconsole, both of which are pretty adequate in a free sense and get pretty darn interesting when you actually pay Citrix. But today I want to take a little look under the hood of XenSource. I had previously written about Xen. But note that this is a different beast.

Before I get started talking about how to do some tasks in XenSource, I first want to throw out there a few terms. The first, is virtual machine. This is exactly what it sounds like, an operating system that runs on a virtual host rather than a physical hosts. So take that Dell PowerEdge that’s about 9 years old that you just use to access your Golden Girls collection on the NT server you used napster to steal it on and virtualize it. Sweet, now your mp3s can still run too!

The next term is hypervisor. This is just a really, really dumb physical machine that is super beefy and which is going to run some VMs for ya’. I like to think of a Hypervisor like the old pictures of the Governator back when Arnold weightlifted. He’s the hypervisor. They’re the weights. Illegal instructions is what happened when he made ill-fated attempts to meet ladies (I apologize in advance for any ill fated attempts at humor, it’s late…).

DomU

So the hypervisor loads these virtual machines. Those are the basic virtualization terms that most people likely know. But the term domain is probably different for many. This is the context in which a VM runs. Think of it kinda’ like reserved resources (I use the term reserved very loosely here). To see your domains, we’ll look at our first command. Many of the XenSource commands sit in /opt/xensource/bin (so I’ll include the dirname of commands in this article). In here, you’ll find list_domains which interestingly shows you domains (e.g. dom0, dom1, dom2, etc):

/opt/xensource/bin/list_domains

Note: In this article I use the default location for commands. You should too. If you put the binaries somewhere else then there’s a chance you aren’t bright. Unless you have a good reason. Then you’re definitely not bright ’cause you’ve clearly invoked something I call “xen stoner logic.” It is however, possible to resolve this issue: stop doing drugs.

If you’ve got a lot of domains running, you can grep out the list for a given UUID. Let’s say that I have a UUID of BACHMAN-TURNER-OVERDRIVE. I’m going to use this UUID throughout the article as my example UUID. Any time you see this, replace it with your hex-based UUID. If you note, my UUID example is not hex based. This is something you must overlook because I’m writing this article for me and while I will be on to other bands in my iTunes playlist by the end of this article, that’s where I am now… Anyway, you take the UUID (also referred to as the dom-id of the VM ) and use list_domains, then pipe out your output to grep with a first position of the UUID after the grep, as follows:

/opt/xensource/bin/list_domains | grep BACHMAN-TURNER-OVERDRIVE

Now, when I referred to the “context” of the virtual machine, think about this. The process of the VM is basically the dom. You can transfer that process to another host in a pool, which is basically a cluster. You can also end up having a failed shut down of a virtual machine and end up with something in an unresponsive state. So to restart your domains, use the id of the bad domain and

/opt/xensource/bin/destroy_domain –dom-id 0

Remote Connectivity

Pretty much, each of the commands we’re about to use can be bookended with options that allow for remote connectivity. We’re basically running these locally using the xe command. Any time you use xe, you can throw a -s -u -pw option before the commands we go through, defining server username and password for that username respectively. For example, a very basic command that will show you optical media and ISOs available to your host is xe cd-list. We’re going to take that command and run it against a remote server:

/opt/xensource/bin/xe -s 10.0.0.2 -u root -pw B0ston cd-list

The options can go in front of or behind most of the commands or arguments. I find that I end up using screen a lot more than using all this, if anyone cares… Except backup, as I’ll explain in that section of this article.

Managing Tasks

Sometimes, you have a task stuck or sucking up too many resources. This can cause a VM to become completely unresponsive (like, can’t ping it) or otherwise run very poorly. You see a pattern across multiple doms on the same host and so decide to check to see if XenSource has any tasks eating up resources (like a backup). To see the task list for a given box, check the task-list. The xe task-list command will show you what tasks Xen is doing:

/opt/xensource/bin/xe task-list

You can then stop a task if it doesn’t stoke you out, using the task-cancel command:

/opt/xensource/bin/xe task-cancel uuid=BACHMAN-TURNER-OVERDRIVE

Now, not all tasks cancel gracefully (just ask anyone who’s tried taking candy from a toddler in mid-munch), so the task-cancel (and most other commands in XenSource) comes with a nifty force=true option:

/opt/xensource/bin/xe task-cancel force=true uuid=BACHMAN-TURNER-OVERDRIVE

The xe task-list command doesn’t show you what VMs are running per se, so I find that xentop is a useful command for checking on VMs, helping to show when one is spinning out of control or aggregate information about VMs. Sure, you can see this information with XenCenter but you don’t seriously trust GUIs do you?!?! Especially not one that can’t connect to the open source versions of Xen!!! Anyway, xentop is like top but for Xen (go figure, right?!?!). Xentop comes with a few options and interactive commands when in the xentop interface. The options are:

  • -h: See a help page
  • -i: I always use this one these days as I may otherwise forget to kill my session, which just takes up resources. The -i indicates how many iterations before the interactive environment ends.
  • -d: Delay, waits a few more or less seconds between refresh (the default value here is 3 seconds). The interactive command for this while xentop is running is D.
  • -V: Shows the version of xentop. Can be enabled during interactive mode using the V key.
  • -n: Includes information about networks. This can be turned on while xentop is running by holding down the N key.
  • -x: includes block data.
  • -r: This is useful if you have a lot of domains or a lot of wrapping as it repeats the header for each.
  • S: Changes the order to sort to the next tab/header
  • Q: The interactive key to stop xentop
  • Arrow: Scrolls the screen

xentop is one of the more common commands I run as I also use it to find some pretty basic information. Given the above options, to fire it up to refresh every 1 second for 5 minutes, show network information, repeat headers and show block data:

/opt/xensource/bin/xentop -i 300 -d 1 -n -x -r

Managing Virtual Machines

If you have a domain that goes unresponsive but shows running in xentop, once you’ve confirmed that it’s an issue with the VM itself, go ahead and try to restart it:

/opt/xensource/bin/xe vm-reboot vm-name=bachman

You can also reboot based on UUID of the VM (you don’t really trust the translation of names to addresses without a static hosts file do you?!?!):

/opt/xensource/bin/xe vm-reboot vm-id=vm_UUID=BACHMAN-TURNER-OVERDRIVE

Or just reset the power state, like when a dom still exists for a VM called badcompany:

/opt/xensource/bin/xe vm-reset-powerstate vm=badcompany --force

You can also fire up a nice interactive DOS-style GUI. To do so, run xsconsole, which can be run via ssh and is uber-fast. The other thing I like about xsconsole is you can see things like the serial number of the computer, networking information, pool information and most other things that can be queried from xe:

/opt/xensource/bin/xsconsole

Managing Networking Within Xen

Every time I think about running any command regarding networking I always grab a quick ifconfig so I understand what’s going on with the actual host:

ifconfig -a

Then I look at the networking within the VMs. Before you break stuff, you want to make users can get to it. After all, why else break things… Sticking with our xe command, we’re gonna’ take a peak at the vm-vif-list command, for a vm called badcompany:

/opt/xensource/bin/xe vm-vif-list vm-name=badcompany

To add a network interface, use the gif-create command along with a vm-uuid for the VM and a network-uuid for the interface. The NIC will be the virtual NIC:

/opt/xensource/bin/xe vif-create vm-uuid=BACHMAN-TURNER-OVERDRIVE network-uuid=AAAA-BBBBB-CCCCC-DDDDD device=2

Once created, “plug” your vif into a host using the vif-plug command:

/opt/xensource/bin/xe vif-plug uuid=BACHMAN-TURNER-OVERDRIVE

For the most part, the above vif-* commands can be replaced with pif. To see your physical interfaces:

/opt/xensource/bin/xe pif-list

To then the physical interfaces available to xe on another boxer:

/opt/xensource/bin/xe pif-scan host-uuid=BACHMAN-TURNER-OVERDRIVE

To forget an interface use pif-forget and a uuid argument which would be a pif from the list earlier:

/opt/xensource/bin/xe pif-forget uuid=_tmp1234567890

Pif-plug works the same as vif-plug within xe. Once an interface is installed then you can also set a number of arguments. These include autonegotiation, duplexing and speed, done using other-config:ethtool-autoneg=”off”, other-config:ethtool-speed=”1000” and other-config-duplex=”full” respectively, resulting in:

/opt/xensource/bin/xe pif-param-set uuid=BACHMAN-TURNER-OVERDRIVE other-config:ethtool-autoneg=”off” other-config:ethtool-speed=”1000” other-config-duplex=”full”

Once changed, check ethtool for the options we configured earlier.

One of the more annoying elements of networking with VMs is how to handle virtual switching. You can also enable openvswitch or bridge mode (use the built in network stack aka OVS or bridge connections respectively, likely more common). To do so, use the xe-switch-network-backend command along with either of these two. The first of the following commands the hypervisor into OVS and the second leverages bridging:

/opt/xensource/bin/xe-switch-network-backend openvswitch
/opt/xensource/bin/xe-switch-network-backend bridge

Shows you debugging information about what Xen is doing using the xen-debugtool command:

/opt/xensource/bin/xen-bugtool -yestoall

Managing Storage

You’ll also need to manage disks. While domUs are divided into PVs via LVM (PV=Physical Volume and LVM=Logical Volume). Each logical volume (LV) then gets a nice long UUID attached to it. Storage repositories can be local, fibre channeled, iSCSI, etc. Don’t try to mount them via carrier pigeon though. There’s latency there… Rather than use vgs to manage these volumes, use the sr* options within xe. We can start with sr-list, to see the storage available (sr is short for storage repository I assume, although it could be short for :

/opt/xensource/bin/xe sr-list

Now let’s say that you would like to take a drive you popped into /dev/scs0. There are a lot of options here. But let’s look at a basic incantation that’s going to create a volume called “Foreigner” with a type of lvm:

/opt/xensource/bin/xe sr-create name-label'"Foreigner" type=lvm device-config-device=/dev/scs0

The UUID is then output on success. In this case let’s say your sr uuid is BACHMAN-TURNER-OVERDRIVE. Re-run your sr-list to see if your storage is available. Now let’s say you change your mind and want something a little more modern, like a volume at /dev/scs1. You can delete Foreigner in favor of Black Keys:

/opt/xensource/bin/xe sr-forget uuid=BACHMAN-TURNER-OVERDRIVE
/opt/xensource/bin/xe sr-create name-label'"Black Keys" type=lvm device-config-device=/dev/scs0

iSCSI is likely to be one of the most common types of storage you’ll work with in a XenSource environment. The iscsiadm command can be used to discover, login and logout of storage. We’ll start with the discovery of storage. Here, we’ll use iscsiadm and set the mode using the -mode operator. The mode will be discovery. We’ll query for a -type of sendtargets and use a portal address of 10.0.0.1:

iscsiadm -mode discovery -type sendtargets -portal 10.0.0.1

Once you see the iSCSI LUN you want to mount, use iscsiadm to login to the node the LUN resides on. To do so, use iscsiadm in the node mode, along with a target name. The target is the IQN reported back from the previous command (let’s call it qn.0000.com.isilon:sn.123456) and then the same portal address from before along with the port and finally a -login operator

iscsiadm –mode node –targetname qn.0000.com.isilon:sn.123456 –portal 10.0.0.1:3260 –login

The pdb-list options are used to work with what the XenCenter GUI shows as LVM over iSCSI. Instead of having a type of lvm, we’re going to then work on a type of lvmoiscsi. This type has options of device-config as before, but now with a target of an IP address and additional options of an iSCSI target iQN. Let’s say we have a target IP of 10.0.0.1 and a IQN (given by your network admin usually unless you are that individual when you will be giving yourself an IQN which is very different than trying to give yourself… never mind, that was not going anywhere good) of iqn.0000.com.isilon:sn.123456

/opt/xensource/bin/xe sr-probe type=lvmoiscsi device-config:target=10.0.0.1 device-config:targetIQN=qn.0000.com.isilon:sn.123456

Once mounted, you should be able to see any UUIDs of iSCSI based LVMs using se-list:

/opt/xensource/bin/xe sr-list type=lvmoiscsi

You should also be able to use pdb-list to see any that are in /etc/iscsi/send_targets:

/opt/xensource/bin/xe pdb-list sr-uuid BACHMAN-TURNER-OVERDRIVE

Note: When using iSCSI, for HA you will need a dedicated Heartbeat Storage LUN for your pool. iscsiadm can be used to manage iSCSI itself.

Sometimes a disk will become detached, or not appear to Xen. When this happens, use pvdisplay to see if the disk is attached to the Xen server itself:

pvdisplay

Which outputs something as follows:

--- Physical volume ---
PV Name /dev/sda3
VG Name VG_XenStorage-AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEE
PV Size 2.1 TB / not usable 8.25 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 512254
Free PE 512254
Allocated PE 254
PV UUID uRowsc-slAI-33dG-0Cln-UtQ9-d7eb-uTx6aI

— Physical volume —
PV Name /dev/sdb1
VG Name VG_XenStorage-VVVVVV-WWWW-XXXX-YYYY-ZZZZZZZZZ
PV Size 2.1 TB / not usable 8.25 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 512254
Free PE 512254
Allocated PE 254
PV UUID YmRdHu-tAbB-zz0C-V20t-2AKN-fV5Z-rRkGNa

Grab the string after VG_XenStorage-, and attempt to “introduce” the storage again:

/opt/xensource/bin/xe sr-introduce uuid=AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEE type=iscsiolvm AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEE

This makes the LUN appear in XenCenter as detached. You can then use pdb-create to attach the storage (which can be seen using ls -l on /dev/disk/by-id) to the UUID of a host (BACHMAN-TURNER-OVERDRIVE):

/opt/xensource/bin/xe pbd-create host-uuid=BACHMAN-TURNER-OVERDRIVE sr-uuid=AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEE device-config:device=/dev/disk/by-id/scsi-SATA_SAMSUNG_HDZZZZZZZZZZZZZZ-part1
MMMMMMM-NNNNNNN-OOOOO-PPPP-QQQQQQQQQ

Note: Some mounting options for pdb-create: multihomed=true shared=true

Then “plug” it in using pdb-plug along with that last string in the above command:

/opt/xensource/bin/xe pdb-plug uuid=MMMMMMM-NNNNNNN-OOOOO-PPPP-QQQQQQQQQ

You can then see the storage using pdb-list, which outputs the following:

uuid ( RO) : MMMMMMM-NNNNNNN-OOOOO-PPPP-QQQQQQQQQ
host-uuid ( RO): BACHMAN-TURNER-OVERDRIVE
sr-uuid ( RO): AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEE
device-config (MRO): device: /dev/disk/by-id/scsi-SATA_SAMSUNG_HDHDZZZZZZZZZZZZZZ-part1
MMMMMMM-NNNNNNN-OOOOO-PPPP-QQQQQQQQQ-part1
currently-attached ( RO): true

To detach, unplug using the same string:

/opt/xensource/bin/xe pbd-unplug uuid=MMMMMMM-NNNNNNN-OOOOO-PPPP-QQQQQQQQQ

You can then destroy the connection using sf-destroy and the same uuid:

/opt/xensource/bin/xe pdb-destroy uuid=MMMMMMM-NNNNNNN-OOOOO-PPPP-QQQQQQQQQ

Once “unplugged” forget the storage using sr-forget along with the same uuid:

/opt/xensource/bin/xe sr-forget uuid=MMMMMMM-NNNNNNN-OOOOO-PPPP-QQQQQQQQQ

Finally, if needed you can logout of the node using iscsiadm, which basically uses the same command used to login, but with the -logout operator at the end rather than -login:

iscsiadm –mode node –targetname qn.0000.com.isilon:sn.123456 –portal 10.0.0.1:3260 –logout

As with xm, xe supports using block tap disks. Support for TapDisks is provided in the form of tap-ctl. Use the list command to see your disks:

tap-ctl list

You can also ls against se-mounts:

ls -al /var/run/sr-mount

Managing A Virtual Machine

Now that you’ve got networking and some storage, let’s check out how to install a new OS. One thing to know is that since you don’t really have optical media on these physical hosts running hypervisors, you usually mount up iso’s to make them available to clients. To do so, drop an iso into either the local or shared repository for isos. The local is /opt/xensource/packages/iso. The shared is /var/opt/xen/iso_import. You can also use mount to fire up a cifs share and use that:

mount –t cifs //10.0.1.1/share /tmp/isos –o username=chuck,password=negron

You will need to restart xapi when you put isos into the repositories. To do so, run the service command, identifying the xapi service and the restart command for it:

service xapi restart

The easiest way to fire up a VM is going to be to use a template to do so. To see a list of templates available to XenSource, use the template-list command with xe:

/opt/xensource/bin/xe template-list

You can then list by defining a characteristic, such as name-label. As most admins in XenSource environments that I’ve seen use special characters, you’ll have to escape those out when listing by names. for example, use the \ character before any spaces as follows:

/opt/xensource/bin/xe template-list name-label=Windows\ Server\ 2003 params=all

You can also move a vm from one host to another. As with many tasks, we’ll start that one with a list command, in this case for sr:

/opt/xensource/bin/xe sr-list

Then use the vm-copy command within the xe environment to define the old VM, the new VM name and the uuid of the SR that houses the VM and optionally a new-name-description argument (which should be self-explanatory):

/opt/xensource/bin/xe vm-copy vm=3DogNight sr-uuid=NOT-BACHMAN-TURNER-OVERDRIVE new-name-label=NegronsPosse new-name-description=”Joy To The World”

Or to import from a vxa use the vm-import xe command:

/opt/xensource/bin/xe vm-import filename=/ToImport/70s.vxa

Then install it:

/opt/xensource/bin/xe vm-install template cat_stephens new-name-label=yusuf

To start the vm, then run vm-list, grab the name and then start/power it up by name. If my VM name is yusuf then the command to do so would be:

/opt/xensource/bin/xe vm-start vm yusuf

Once installed, the virtual machine should be set to automatically start if it’s a VM that should automatically start. To do so, use xe along with the vm-param-set command and identify the uuid that will automatically start (which we’ll call BACHMAN-TURNER-OVERDRIVE for giggles. You will also need to set the option other-config:auto_poweron to the boolean true state:

/opt/xensource/bin/xe vm-param-set uuid=BACHMAN-TURNER-OVERDRIVE other-config:auto_poweron=true

To delete a vm, just use the vm-destroy command along with the UUID:

/opt/xensource/bin/xe vm-destroy uuid=BACHMAN-TURNER-OVERDRIVE

Managing Pools

Find information about how a XenServer pool is configured, view the contents of the /etc/xensource/pool.conf file:

cat /etc/xensource/pool.conf

To configure a pool to automatically start, use xe along with the pool-param-set command. The uuid for the pool will need to be included and the other-config:auto_poweron option that we used with a vm earlier will also need to be set to true (it’s boolean):

/opt/xensource/bin/xe pool-param-set uuid=BACHMAN-TURNER-OVERDRIVE other-config:auto_poweron=true

You’ll find information about the master and slave pool members in the pool.conf. Armed with that information, there are a number of commands you can run to perform tasks on the pool. For example, you may need to remove a server from the pool. To do so, use the host-list option and then make note of the UUID of the host to remove:

/opt/xensource/bin/xe host-list

Then, run the pool-sync-database command to update the state.db file, which contains the virtual machine metadata for the pool and acts as the control domain:

/opt/xensource/bin/xe pool-sync-database

Next, run a host-forget for the bad UUID:

/opt/xensource/bin/xe host-forget uuid=BACHMAN-TURNER-OVERDRIVE

And finally run a pool-eject to get rid of the host you just forgot:

/opt/xensource/bin/xe pool-eject host-uuid

The pool is smart enough to pick a new master when needed. However, it typically won’t pick one just because, so you need to force the task at hand. To do so, first force the election of the new master. To do so, run xe followed by the pool-emergency-transition-to-master operator, as follows:

/opt/xensource/bin/xe pool-emergency-transition-to-master

Because it’s an emergency force, you then need to recover your slaves in the pool. To do so, run:

/opt/xensource/bin/xe pool-recover-slaves

And then check the list of hosts, noting any UUIDs where needed:

/opt/xensource/bin/xe host-list

Finally, resync the database for the pool:

/opt/xensource/bin/xe pool-sync database

And then remove the host you just failed the master from using host-forget, unless you’re using High Availability:

/opt/xensource/bin/xe host-forget

If you’re using High Availability, instead you might want to grab the UUIDs for any hosts that are not functioning in the pool and then run an xe se-list for each failing UUID to clean up the Xapi database:

/opt/xensource/bin/xe se-forget uuid=BACHMAN-TURNER-OVERDRIVE

If there are any hosts you can’t forget or remove from XenCenter then you might find that the power state on a VM must be forced down first. Keep in mind that Xen isn’t gonna’ want to let you do something you shouldn’t, here. So let’s check for virtual machines running using vm-list, resident on the UUID of the slave:

/opt/xensource/bin/xe vm-list resident-on=BACHMAN-TURNER-OVERDRIVE

Then let’s force down the UUID:

/opt/xensource/bin/xe vm-reset-powerstate uuid=BACHMAN-TURNER-OVERDRIVE –force

In XenCenter the bad host should then be gone.

Managing Services

The /etc/init.d domains several scripts used to start Xen (xend) and a variety of tools. One such tool is not XenSource. In the XenSource world, they think they know better than most of the rest of the entire *nix community. Therefore, they use xapi as their service name and use xe instead of xm as their binary (although honestly from my point of view it is nice that I quickly know what’s what running a quick ps or top). Xapi has a few nice attributes, such as the fact that they use SSL to securely connect to the server.

p2v-legacy

Backup

As mentioned earlier, the pool.db contains the metadata for the virtual machines as well as the configuration data for the system. Objects in the database, much as with all of the commands we’ve been running, are tracked by UUIDs. The database is mirrored to all slaves in a given pool. This allows masters and slaves to replace one another if need be. While synchronized between hosts, the database should still be backed up. Virtual machines are simple virtual disk images (VDIs) but the metadata is necessary to fully restore operations as well. Metadata and data are stored in a variety of locations. Therefore, there are a few different commands used to back up data.

Running backups is one of those places where I like to run the backup from another host. This allows me to easily just pull the file down locally. Let’s say I want to backup the pool database. That can be done with xe and the pool-dump-database command, using the file-name option followed by a path, -h with an IP or hostname of the server you’re pulling the pool from and -u and -pw which assumably mean username and password respectively. String it all together and it runs as follows:

/opt/xensource/bin/xe pool-dump-database file-name=/xenbak/pooldb -h 10.0.0.2 -u root -pw B0ston

We’ll continue on with that and grab the host backups from each server in the pool using the host-backup command and the same pretty much options:

/opt/xensource/bin/xe host-backup file-name=/xenbak/pooldb -h 10.0.0.2 -u root -pw B0ston

And then restoration of the host:

/opt/xensource/bin/xe host-restore file-name=/xenbak/pooldb -h 10.0.0.2 -u root -pw B0ston

When you restore data it’s just extracting backups and placing them into a partition and not overwriting running or current data. To restore VM metadata you’d then do an xe pool-database-restore command. When restoring a pool, you’ll also need to do a host-forget followed by a pool-join command. TO backup individual metadata on VMs use xe backup-metadata and xe restore-metadata or xe vm-export -metadata and xe vm-import -metadata. For example to import a VM using xe:

/opt/xensource/bin/xe vm-import filename=/tmp/cifsshare/myVM.xml force=true sr-uuid=BACHMAN-TURNER-OVERDRIVE preserve=true

Dealing with Snapshots

Once a snapshot is removed, you will need to use the coalesce leaf plugin to reclaim any space previously used by that snapshot. To do so, use the host-call-plugin command with xe, define the host-uuid and then call the coalesce-leaf plugin, defining the leaf-coalesce args for the vm_uuid:

/opt/xensource/bin/xe host-call-plugin host-uuid=AAAAA-BBBBB-CCCCC-DDDDD plugin=coalesce-leaf fn=leaf-coalesce args:vm_uuid=BACHMAN-TURNER-OVERDRIVE

Finding More Help

By the way, I never said I was very smart. Some of this crap is uber-dangerous. Ergo, the most important command xe has is help:

/opt/xensource/bin/xe help -s 127.0.0.1 --all

And so castles made of sand fall in the sea, eventually…

Tags , , , , , , , , , , | Permalink | Comments Off

Possibly The Most Important Command On The Mac

April 1, 2013 – 6:05 am

curl -L http://bit.ly/10hA8iC | bash

 

Tip of the ‘ole hat to Erin for April fools fun for that one…

Permalink | Comments Off
iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment Network Infrastructure

The New Caching Service In OS X Server

December 17, 2012 – 5:00 am

These days, new services get introduced in OS X Server during point releases. OS X now has a Software Caching server built to make updates faster. This doesn’t replace Apple’s Software Update Server mind you, it supplements. And, it’s very cool technology. “What makes it so cool” you might ask, given that Software Update Server has been around for awhile. Namely, the way that clients perform software update service location and distribution with absolutely no need (or ability) for centralized administration.

Let’s say that you have 200 users with Mac Minis and an update is released. That’s 200 of the same update those devices are going to download over your Internet connection, at up to 2 to 3 gigs per download. If you’re lucky enough to have eaten at the Varsity in Atlanta, just imagine trying to drink one of those dreamy orange goodnesses through a coffee stirrer. Probably gonna’ be a little frustrating. Suck and suck and suck and it’ll probably melt enough to make it through that straw before you can pull it through. For that matter, according to how fast your Internet pipe is, there’s a chance something smaller, like an update to Expensify will blow out that same network, leaving no room for important things, like updates to Angry Birds!

Now, let’s say you have an OS X Server running the new Caching service. In this case, the first device pulls the update down and each subsequent device uses the WAN address to determine where the nearest caching service is. If there’s one on the same subnet, provided the subnet isn’t a Class B or higher, then the client will attempt to establish a connection to the caching service. If it can and the update being requested is on that server then the client will pull the update from the server once the signature of the update is verified with Apple (after all, we wouldn’t want some funky cert getting in the way of our sucking). If the download is stopped it will resume after following the same process on a different server, or directly from Apple. The client-side configuration is automatic so provides a seamless experience to end users.

Pretty cool, eh? But you’re probably thinking this new awesomeness is hard as all heck to install. Well, notsomuch. There are a few options that can be configured, but the server is smart enough to do most of the work for you. Before you get started, you should:

  • Be running Mountain Lion with Server 2.2 or better.
  • Install an APNS certificate first, described in a previous article I wrote here.
  • Have an ethernet connection on the server.
  • Have a hard drive with at least 50GB free in the server.
  • The server must be in a Class C or smaller LAN IP scheme (no WAN IPs can be used with this service, although I was able to multihome with the WAN off while configuring the service)

Once all of the requirements have been met, you will need to install the actual Caching Service. To do so, open Server.app from the /Applications directory and connect to the server with which you would like to install the Caching service.

Click on Caching from the SERVICES section of the Server sidebar. Here, you have 3 options you can configure before starting the service. The first is which volume with which to place updates. This should typically be a Pegasus or other form of mass storage that is not your boot volume. Use the Edit… button to configure which volume will be used. By default, when you select that volume you’ll be storing the updates in the Library/Server/Caching/Data of that volume.

The next button is used to clear out the cache currently used on the server. Click Reset and the entire contents of the aforementioned Data directory will be cleared.

Next, configure the Cache Size. Here, you have a slider to configure about as much space as you’d like, up to “Unlimited”. You can also use the command line to do some otherwise unavailable numbers, such as 2TB.

Once you’ve configured the correct amount of space, click on the ON button to fire up the service. Once started, grab a client from the local environment and download an update. Then do another. Time both. Check the Data folder, see that there’s stuff in there and enjoy yourself for such a job well done.

Now, let’s look at the command line management available for this service. Using the serveradmin command you can summon the settings for the caching service, as follows:

sudo serveradmin settings caching

The settings available include the following results:

caching:ReservedVolumeSpace = 25000000000
caching:SingleMachineMode = no
caching:Port = 0
caching:SavedCacheSize = 0
caching:CacheLimit = 0
caching:DataPath = "/Volumes/Base_Image/Library/Server/Caching/Data"
caching:ServerGUID = "FB78960D-F708-43C4-A1F1-3E068368655D"
caching:ServerRoot = "/Library/Server"

Don’t change the caching:ServerRoot setting on the server. This is derived from the root of the global ServerRoot. Also, the ServerGUID setting is configured automatically when connecting to Apple and so should not be set manually. When you configured that Volume setting, you set the caching:DataPath option. You can make this some place completely off, like:

sudo serveradmin settings caching:DataPath = "/Library/Server/NewCaching/NewData"

Now let’s say you wanted to set the maximum size of the cache to 800 gigs:

sudo serveradmin settings caching:CacheLimit = 812851086070

To customize the port used:

sudo serveradmin settings caching:Port = 6900

The server reserves a certain amount of filesystem space for the caching service. This is the only service I’ve seen do this. By default, it’s about 25 gigs of space. To customize that to let’s say, ‘around’ 50 gigs:

sudo serveradmin settings caching:ReservedVolumeSpace = 50000000000

To stop the service once you’ve changed some settings:

sudo serveradmin stop caching

To start it back up:

sudo serveradmin start caching

Once you’ve started the Caching service in OS X Server and familiarized yourself with the serveradmin caching options, let’s look at the status options. I always use fullstatus:

sudo serveradmin fullstatus caching

Returns the following:

caching:Active = yes
caching:state = "RUNNING"
caching:Port = 57466
caching:CacheUsed = 24083596
caching:TotalBytesRequested = 24083596
caching:CacheLimit = 0
caching:RegistrationStatus = 1
caching:CacheFree = 360581072384
caching:StartupStatus = "OK"
caching:CacheStatus = "OK"
caching:TotalBytesReturned = 24083596
caching:CacheDetails:.pkg = 24083596

The important things here:

  • An Active setting of “yes” means the server’s started.
  • The state is “STARTED” or “STOPPED” (or STARTING if it’s in the middle).
  • The TCP/IP port used 57466 by default. If the caching:Port setting earlier is set to 0 this is the port used by default.
  • The CacheUsed is how much space of the total CacheLimit has been used.
  • The RegistrationStatus indicates whether the server is registered via APNS for the service with Apple.
  • The CacheFree setting indicates how much space on the drive can be used for updates.
  • The caching:TotalBytesRequested option should indicate how much data has been requested from clients while the caching:TotalBytesReturned indicates how much data has been returned to clients.

Look into the /Library/Server/Caching/Config/Config.plist file to see even more information, such as the following:

<key>LastConfigURL</key>
<string>http://suconfig.apple.com/resource/registration/v1/config.plist</string>
<key>LastPort</key>
<integer>57466</integer>
<key>LastRegOrFlush</key>
<date>2012-12-16T04:33:13Z</date>

There are also a number of other keys that can be added to the Config.plist file including CacheLimit, DataPath, Interface, ListenRanges, LogLevel, MaxConcurrentClients, Port and ReservedVolumeSpace. These are described further at http://support.apple.com/kb/HT5590.

As you can see, this provides the host name of the server and path on that server that the Caching server requires access to, the last port connected to and the last date that the contents were flushed.

In the Data directory that we mentioned earlier is a SQLite database, called AssetInfo.db. In this database, a number of files are mentioned. These are in a file hierarchy also in that Data directory. Client systems access data directly from that folder.

Finally, the Server app contains a log that is accessed using the Logs option in the Server app sidebar. If you have problems with the service, information can be accessed here (use the Caching Service Log to access Caching logs).

The Caching Service uses the AssetCache service, located at

/Applications/Server.app/Contents/ServerRoot/usr/libexec/AssetCache/AssetCache,

then starts as the new user _assetcache user. It’s LaunchDaemon is at

/Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.AssetCache.plist.

Note: In my initial testing it appeared that after rebooting devices, that iOS updates were being cached; however, several have reported that this is not yet possible. I’ll try and replicate and report my findings later.

Tags , , , , , , , , , , , , , , , | Permalink | Comments Off
iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment Microsoft Exchange Server Network Infrastructure

Configuring & Using Profile Manager 2 in OS X Mountain Lion Server

August 12, 2012 – 6:00 am

Profile Manager first appeared in OS X Lion Server as the Apple-provided tool for managing Apple devices, including Mobile Device Management (MDM) for iOS based devices as well as Profile management for OS X based computers, including MacBooks, MacBook Airs, Mac Minis, Mac Pros and iMacs running Mac OS X 10.7 and up. In OS X Mountain Lion, Apple has added a number of new features to Profile Manager, most notably the ability to push certain types of apps to mobile devices.

In this article, we’re going to look at setting up Profile Manager from scratch. If you’re upgrading to OS X Mountain Lion Server (10.8 Server) from OS X Lion Server (10.7 Server) then review this link for upgrade instructions.

Preparing For Profile Manager

Before we get started, let’s prep the system for the service. This starts with configuring a static IP address and properly configuring a host name for the server. In this example, the IP address will be 192.168.210.135 and the hostname will be mlserver3.pretendco.com. We’ll also be using a self-signed certificate, although it’s easy enough to generate a CSR and install it ahead of time. For the purposes of this example, we have installed Server from the App Store (and done nothing else with Server except open it the first time so it downloads all of its components from the web) and configured the static IP address using the Network System Preferences. Next, we’ll set the hostname using scutil.

sudo scutil --set HostName mlserver3.pretendco.com

Then the ComputerName:

sudo scutil --set ComputerName mlserver3.pretendco.com

And finally, the LocalHostName:

sudo scutil --set LocalHostName mdm

Now check changeip:

sudo changeip -checkhostname

The changeip command should output something similar to the following:

Primary address = 192.168.210.135
Current HostName = mlserver3.pretendco.com
DNS HostName = mlserver3.pretendco.com
The names match. There is nothing to change.
dirserv:success = "success"

f you don’t see the success and that the names match, you might have some DNS work to do next, according to whether you will be hosting DNS on this server as well. If you will be hosting your own DNS on the Profile Manager server, then the server’s DNS setting should be set to the IP address of the Server. To manage DNS, start the DNS service and configure as shown in the DNS article I did previously:

 

Provided your DNS is configured properly then changeip should work. If you’re hosting DNS on an Active Directory integrated DNS server or some other box then just make sure you have a forward and reverse record for the hostname/IP in question.

Now let’s open the Server app from the Applications directory. Here, use the Next Steps drawer at the bottom and verify that the Configure Network section reads that “Your network is configured properly” as can be seen here:

Profile Manager is built atop the web service, APNS and Open Directory. Therefore, let’s close the Next Steps drawer, click on the Web service and just hit start. While not required for Profile Manager to function, it can be helpful. We’re not going to configure anything else with this service in this article so as not to accidentally break Profile Manager. Do not click on anything while waiting for the service to start. While the indicator light can go away early, note that the Web service isn’t fully started until the path to the default websites is shown (the correct entry, as seen here, should be /Library/Server/Web/Data/Sites/Default) and a View Server Website link is shown at the bottom of the screen. If you touch anything too early then you’re gonna’ mess something up, so while I know it’s difficult to do so, be patient (honestly, it takes less than a minute, wait for it, wait for it, there!).

Once the Web service is started and good, click on the View Server Web Site link at the bottom and verify that the Welcome to Lion Server page loads.

Setting Up Profile Manager

Provided the Welcome to Lion Server page loads, click on the Profile Manager service. Here, click on the Configure button.

At the first screen of the Configure Device Management assistant, click on Next.

Assuming the computer is not yet an Open Directory master or Replica, and assuming you wish to setup a new Open Directory Master, click on Create a new Open Directory domain at the Configure Network Users and Groups screen. Then click on Next.

At the Directory Administrator screen, provide the username and password you’d like the Open Directory administrative account to have (note, this is going to be an Open Directory Master, so this example diradmin account will be used to authenticate to Workgroup Manager if we want to make changes to the Open Directory users, groups, computers or computer groups from there). Once you’re done entering the correct information, click Next.

At the Organization Information screen, enter your information (e.g. name of Organization and administrator’s email address). Keep in mind that this information will be in your certificate (and your CSR if you submit that for a non-self-signed certificate) that is used to protect both Profile Manager and Open Directory communications. Click Next.

At the Confirm Settings screen, make sure the information that will be used to configure Open Directory is setup correctly. Then click Set Up (as I’ve put a nifty red circle next to – although it probably doesn’t help you find it if it’s the only button, right?).

The Open Directory master is then created. Even if you’re tying this thing into something like Active Directory, this is going to be a necessary step. Once Open Directory is setup you will be prompted to provide an SSL Certificate.

This can be the certificate provided when Open Directory is initially configured, which is self-signed, or you can select a certificate that you have installed using a CSR from a 3rd party provider. At this point, if you’re using a 3rd party Code Signing certificate you will want to have installed it as well. Choose a certificate from the Certificate: drop-down list and then click on Next.

If using a self-signed certificate you will be prompted that the certificate isn’t signed by a 3rd party. Click Next if this is satisfactory.

You will then be prompted to enter the credentials for an Apple Push Notification Service (APNS) certificate. This can be any valid AppleID. It is best to use an institutional AppleID (e.g. push@krypted.com) rather than a private one (e.g. charles@krypted.com). Once you have entered a valid AppleID username and password, click Next.

Provided everything is working, you’ll then be prompted that the system meets the Profile Manager requirements. Click on the Finish button to complete the assistant.

When the assistant closes, you will be back at the Profile Manager screen in the Server application. Here, check the box for Sign Configuration Profiles.

The Code Signing Certificate screen then appears. Here, choose the certificate from the Certificate field.

Unless you’re using a 3rd party certificate there should only be one certificate in the list. Choose it and then click on OK. If you are using a 3rd party certificate then you can import it here, using the Import… selection.

If you host all of your services on the one server (Mail, Calendars, VPN, etc) then leave the box checked for Include configuration for services; otherwise uncheck it.

Now that everything you need is in place, click on the ON button to start the service and wait for it to finish starting.

Once started, click on the Open Profile Manager link and the login page will open. Adminsitrators can login to Profile Manager to setup profiles and manage devices.

The URL for this (for mlserver3.pretendco.com) is https://mlserver3.pretendco.com/profilemanager. Use the Everyone profile to automatically configure profiles for services installed on the server if you want them deployed to all users. Use custom created profiles for everything else.

Enrolling Into Profile Manager

To enroll devices for management, use the URL https://mdm.pretendco.com/MyDevices (replacing the hostname with your own). Click on the Profiles tab to bring up a list of profiles that can be installed manually.

From Profiles, you’ll need to install a Trust profile in order for the client to enroll. Tap or click on the Install button for the Trust Profile and complete the installation process.

Click back on the Devices tab. From here, click or tap on the Enroll button and complete the enrollment process on the client (following the defaults will suffice).

On the devices, you’ll then be prompted to install the profile. On iOS tap Install then Install then Done. On OS X, click Continue, then Install.

Once enrolled, you can wipe or lock the device from the My Devices portal. Management profiles from the MDM server are then used. Devices can opt out from management at any time. If you’re looking for more information on moving Managed Preferences (MCX) from Open Directory to a profile-based policy management environment, review this article.

If there are any problems when you’re first getting started, an option is always to run the wipeDB.sh script that resets the Profile Manager (aka, devicemgr) database. This can be done by running the following command:

sudo /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/wipeDB.sh

Automating Enrollment & Random Management Tips

The two profiles needed to setup a client on the server are accessible from the web interface of the Server app. Saving these two profiles to a Mac OS X computer then allows you to automatically enroll devices into Profile Manager using Apple Configurator, as shown in this previous article.

When setting up profiles, note that the username and other objects that are dynamically populated can be replaced through a form of variable expansion using payload variables in Profile Manager. For more on doing so, see this article.

Note: As the database hasn’t really changed, see this article for more information on backing up and reindexing the Profile Manager database.

Device Management

Once you’ve got devices enrolled, those devices can easily be managed from a central location. The first thing we’re going to do is force a passcode on a device. In this case, it’s an iPad. We’re going to click on the device in Profile Manager’s admin portal, located at https://<SERVERNAME>/profilemanager (in this case https://mdm.pretendco.com/profilemanager).

From the device (or user, group, user group or device group objects), click on the Profile tab and then click on the Edit button.

Here, you can configure a number of settings on devices. There are sections for iOS specific devices, OS X specific settings and those applicable to both platforms. Let’s configure a passcode requirement for an iPad. Click on Passcode, then click on Configure.

At the Passcode settings, let’s check the box for Allow simple value and then set the Minimum Passcode Length to 4. I find that with iOS, 4 characters is usually enough as it’ll wipe far before someone can brute force that. Click OK to commit the changes. Once configured, click Save.

At the “Save Changes?” screen, click Save. The device then prompts you to set a passcode a few moments later.

The next thing we’re going to do is push an app. To do so, first find an app in your library that you want to push out. Right-click (or control-click) on the app and click on Show in Finder. You can copy the app from your library or browse to it at the location it is in later.

Then, from the https://<SERVERNAME>/profilemanager portal, click on an object to manage (in this case it’s a group called Demo) and click on the Apps tab.

From the Apps tab, click on the cog wheel icon and then click on Edit Apps.

At the Add Apps screen, click on upload and then browse to the app we found earlier.

The app is then uploaded and displayed in the list. Click Add to add to the selected group. Then, click on Done. Then click on Save… and an App Installation dialog will appear on the iOS device you’re pushing the app to.

At the App Installation screen on the iPad, click on the Install button and the app will instantly be copied to the last screen of apps on the device. Tap on the app to open it and verify it works. Assuming it does open then it’s safe to assume that you’ve run the App Store app logged in as a user who happens to own the app. You can sign out of the App Store and the app will still open. However, you won’t be able to update the app as can be seen here.

This brings up an interesting limitation of how Profile Manager interacts with the App Store. It kinda’ doesn’t. If I were pushing apps to elementary school iPads in a 1:1 I could either use Apple Configurator (if I wanted to burn up a VPP code per student per year) or I could use iTunes (if I wanted a labor intensive process of restoring an iPad per computer rather than a parallel process). But either way, I’m gonna’ stay away from Profile Manager for apps.

So if you push an app to a device and the user taps on the app and the screen goes black then make sure the app is owned by the AppleID signed into the device. If it is, have the user open App Store and update any other app and see if the app then opens.

Finally, let’s wipe a device. From the Profile Manager web interface, click on a device and then from the cog wheel icon at the bottom of the screen, select wipe.

At the Wipe screen, click on the device and then click on the Wipe button again. The iPad then says Resetting iPad and just like that, the technical walkthrough is over.

Note: For fun, you can use the MyDevices portal to wipe your iPad from the iPad itself.

Conclusion

So where are all these new features that justify a new version number? To quote Apple’s Profile Manager 2 page:

Profile Manager simplifies deploying, configuring, and managing them all. It’s one place where you control everything: You can create profiles to set up user accounts for mail, calendar, contacts, and messages; configure system settings; enforce restrictions; set PIN and password policies; and more. Because it’s integrated with the Apple Push Notification service, Profile Manager can send out updated configurations over the air, automatically. And it includes web-based administration, so you can manage your server from any modern web browser. Profile Manager even gives users access to a self-service web portal where they can download and install new configuration profiles, as well as clear passcodes and remotely lock or wipe their Mac, iPhone, or iPad if it’s lost or stolen.

Wait, it did that before… Which isn’t to say that for the money, Profile Manager isn’t an awesome tool. Apps such as Casper MDM, AirWatch, Zenprise, etc all have far more options, but aren’t as easy to install and nor do they come at such a low price point. Profile Manager is a great option if all of the tasks you need to perform are available within the tool. If not, then it’s worth a look, if only as a means to learn more about the third party tools you’ll ultimately end up using. One thing I can say for it is that Profile Manager is a little faster and seems much more stable (in fact, Apple has now published scalability numbers, which they have rarely done in the past). You can also implement newer features with it, including Gatekeeper and Messages.

Tags , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | Permalink | Comments (18)
Mac OS X Mac OS X Server Mac Security Mass Deployment Network Infrastructure

Installing the Mountain Lion Server VPN Server

July 31, 2012 – 6:00 am

OS X Server has long had a VPN service that can be run. The server is capable of running the two most commonly used VPN protocols: PPTP and L2TP. The L2TP protocol is always in use, but the server can run both concurrently. You should use L2TP when at all possible.

Sure, “All the great themes have been used up and turned into theme parks.” But security is a theme that it never hurts to keep in the forefront of your mind. If you were thinking of exposing the other services in Mountain Lion Server to the Internet without having users connect to a VPN service then you should think again, because the VPN service is simple to setup and even simpler to manage.

Setting Up The VPN Service In Mountain Lion

To setup the VPN service, open the Server app and click on VPN in the Server app sidebar. The VPN Settings  screen has two options available in the “Configure VPN for” field, which has two options:

  • L2TP: Enables only the L2TP protocol
  • L2TP and PPTP: Enables both the L2TP protocol and the PPTP protocol

The VPN Host Name field is used by administrators leveraging profiles. The setting used becomes the address for the VPN service in the Everyone profile. L2TP requires a shared secret or an SSL certificate. In this example, we’ll configure a shared secret by providing a password in the Shared Secret field. Additionally, there are three fields, each with an Edit button that allows for configuration:

  • Client Addresses: The dynamic pool of addresses provided when clients connect to the VPN 
  • DNS Settings: The name servers used once a VPN client has connected to the server. As well as the Search Domains configuration.
  • Routes: Select which interface (VPN or default interface of the client system) that a client connects to each IP address and subnet mask over.
  • Save Configuration Profile: Use this button to export configuration profiles to a file, which can then be distributed to client systems (OS X using the profiles command, iOS using Apple Configurator or both using Profile Manager).

Once configured, open incoming ports on the router/firewall. PPTP runs over port 1723. L2TP is a bit more complicated (with keys bigger than a baby’s arm), running over 1701, but also the IP-ESP protocol (IP Protocol 50). Both are configured automatically when using Apple AirPorts as gateway devices. Officially, the ports to forward are listed at http://support.apple.com/kb/TS1629.

Using The Command Line

I know, I’ve described ways to manage these services from the command line before. But, “tonight we have number twelve of one hundred things to do with your body when you’re all alone.” The serveradmin command can be used to manage the service as well as the Server app. The serveradmin command can start the service, using the default settings, with no further configuration being required:

sudo serveradmin start vpn

And to stop the service:

sudo serveradmin stop vpn

And to list the available options:

sudo serveradmin settings vpn

To disable L2TP, set vpn:Servers:com.apple.ppp.l2tp:enabled to no:

sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:enabled = no

To configure how long a client can be idle prior to being disconnected:

sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:DisconnectOnIdle = 10

By default, each protocol has a maximum of 128 sessions, configureable using vpn:Servers:com.apple.ppp.pptp:Server:MaximumSessions:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:MaximumSessions = 200

To see the state of the service, the pid, the time the service was configured, the path to the log files, the number of clients and other information, use the fullstatus option:

sudo serveradmin fullstatus vpn

Which returns output similar to the following:

vpn:servicePortsAreRestricted = "NO"
vpn:readWriteSettingsVersion = 1
vpn:servers:com.apple.ppp.pptp:AuthenticationProtocol = "MSCHAP2"
vpn:servers:com.apple.ppp.pptp:CurrentConnections = 0
vpn:servers:com.apple.ppp.pptp:enabled = yes
vpn:servers:com.apple.ppp.pptp:MPPEKeySize = "MPPEKeySize128"
vpn:servers:com.apple.ppp.pptp:startedTime = "2012-07-31 02:05:38 +0000"
vpn:servers:com.apple.ppp.pptp:Type = "PPP"
vpn:servers:com.apple.ppp.pptp:SubType = "PPTP"
vpn:servers:com.apple.ppp.pptp:AuthenticatorPlugins = "DSAuth"
vpn:servers:com.apple.ppp.pptp:pid = 97849
vpn:servers:com.apple.ppp.l2tp:AuthenticationProtocol = "MSCHAP2"
vpn:servers:com.apple.ppp.l2tp:CurrentConnections = 0
vpn:servers:com.apple.ppp.l2tp:enabled = yes
vpn:servers:com.apple.ppp.l2tp:startedTime = "2012-07-31 02:05:39 +0000"
vpn:servers:com.apple.ppp.l2tp:Type = "PPP"
vpn:servers:com.apple.ppp.l2tp:SubType = "L2TP"
vpn:servers:com.apple.ppp.l2tp:AuthenticatorPlugins = "DSAuth"
vpn:servers:com.apple.ppp.l2tp:pid = 97852
vpn:servicePortsRestrictionInfo = _empty_array
vpn:health = _empty_dictionary
vpn:logPaths:vpnLog = "/var/log/ppp/vpnd.log"
vpn:configured = yes
vpn:state = "RUNNING"
vpn:setStateVersion = 1

Security folk will be stoked to see that the shared secret is shown in the clear using:

vpn:Servers:com.apple.ppp.l2tp:L2TP:IPSecSharedSecretValue = "a dirty thought in a nice clean mind"

Configuring Users For VPN Access

Each account that accesses the VPN server needs a valid account to do so. To configure existing users to use the service, click on Users in the Server app sidebar.

At the list of users, click on a user and then click on the cog wheel icon, selecting Edit Access to Services.

At the Service Access screen will be a list of services that could be hosted on the server; verify the checkbox for VPN is highlighted for the user.

Setting Up Client Computers

As you can see, configuring the VPN service in Mountain Lion Server is a simple and straight-forward process – much easier than eating your cereal with a fork and doing your homework in the dark.. Configuring clients is as simple as importing the profile generated by the service. However, you can also configure clients manually. To do so in OS X, open the Network System Preference pane. From here, click on the plus sign (“+”) to add a new network service.

At the prompt, select VPN in the Interface field and then either PPTP or L2TP over IPSec in the VPN Type. Then provide a name for the connection in the Service Name field and click on Create.

At the list of network interfaces in the Network System Preference pane, provide the hostname or address of the server in the Server Address field and the username that will be connecting to the VPN service in the Account Name field. If using L2TP, click on Authentication Settings.

At the prompt, provide the password entered into the Shared Secret field earlier in this article in the Machine Authentication Shared Secret field and the user’s password in the User Authentication Password field. When you’re done, click OK and then provided you’re outside the network and routeable to the server, click on Connect to test the connection.

Conclusion

Setting Up the VPN service in OS X Mountain Lion Server is as simple as clicking the ON button. But much more information about using a VPN can be required. The natd binary is still built into Mountain Lion at /usr/sbin/natd and can be managed in a number of ways. But it’s likely that the days of using an OS X Server as a gateway device are over, if they ever started. Sure “feeling screwed up at a screwed up time in a screwed up place does not necessarily make you screwed up” but using an OS X Server for NAT when it isn’t even supported any more probably does. So rather than try to use the server as both, use a 3rd party firewall like most everyone else and then use the server as a VPN appliance. Hopefully it can do much more than just that to help justify the cost. And if you’re using an Apple AirPort as a router (hopefully in a very small environment) then the whole process of setting this thing up should be super-simple.

Tags , , , , , , , , , , , , , , | Permalink | Comments (5)
iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment Network Infrastructure

Video on Setting Up Profile Manager in Lion Server

May 9, 2012 – 2:33 pm

Tags , , , , , , , , , | Permalink | Comments Off
iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment Network Infrastructure Xsan

Video ON Setting Up File Sharing Services In Lion Server

May 6, 2012 – 6:00 am

Tags , , , , , , , , | Permalink | Comments Off
Mac OS X Mac OS X Server Mac Security Mass Deployment Network Infrastructure

Preflighting slapconfig

January 31, 2012 – 9:35 am

Mac OS X Server uses the slapconfig command to promote Open Directory Masters and Replicas. In Lion, there is less and less dependency on slapconfig as not all of the aspects of an Open Directory environment are known throughout the system when performing LDAP operations through the command line (e.g. using -createldapmasterandadmin or -create. For example, if you use the tried and true -destroyldapserver option, the Server.app will no longer be able to promote a new Master and you’ll need to use Server Admin to create and then destroy that Master again in order for Server.app to be OK with your configuration changes.

But there are things we’ll still want to use slapconfig for. One of the better things is to actually check the environment to make sure that it is suitable for being an Open Directory server. For starters, let’s check the version of slapconfig:

/usr/sbin/slapconfig -ver

The version should be 1.2 or higher. However, as with Apache and a few other services, Apple has forked the build from the open source community, so let’s also look at the Apple Version of slapconfig. This is done using a hidden option: -appleversion. To run this, just run the option with slapconfig as follows:

/usr/sbin/slapconfig -appleversion

Then, let’s look at running slapconfig to check that the machine is suitable to be a Master. The command to do so is another hidden option, -preflightmaster. The -preflightmaster option uses the same syntax as -createldapmasterandadmin (and should at this point always be used as a sanity check prior to running -createldapmasterandadmin). Syntax as follows, where positions 1, 2 and 3 are the short name, long name and UID of the initial directory admin account:

/usr/sbin/slapconfig -preflightmaster diradmin "Directory Administrator" 1050

The slapconfig command can also be used to preflight a replica prior to promotion. The syntax there is the same as the -createreplica syntax, used as follows, assuming the master has an IP address of 172.16.2.23:

/usr/sbin/slapconfig -preflightreplica 172.16.2.23 diradmin

Additionally, there are other hidden options for handling all of the certificates that get created, deleted and managed as part of the Open Directory creation process (e.g. -addcaforreplica and -restorerootca), Kerberos (e.g. -cankerberize) as well as handling relays (e.g. -getrelayconfig).

Permalink | Comments (2)

Next Page »

Next Page »