hi.pe.kr 날으는물고기·´″°³о♡

Supported Distributions

At the time of writing, Configuration Manager 2012 Service Pack 1 offers client support for the following UNIX and Linux distributions;

• Red Hat Enterprise Linux
• Version 4, 5, 6 (x86 and x64)
• Solaris
• Version 9 (SPARC)
• Version 10 (x86 and SPARC)
• SUSE Linux Enterprise Server
• Version 9 (x86)
• Version 10 SP1 (x86 and x64)
• Version 11 (x86 and x64)

In the near future the number of distributions supported will increase, putting Configuration Manager’s UNIX and Linux support in line with System Center Operations Manager. It is also worth pointing out that the support for UNIX and Linux distributions is targeted to the server distributions rather than the client distributions.

Supported Features

The UNIX/Linux client is fairly lightweight in comparison to its Windows (or even Mac) counter parts, with the following natively supported features;

- Hardware inventory
- Inventory of installed software
- Software distribution

No Configuration Manager 2012 infrastructure changes are required to support UNIX/Linux clients, and additionally, as Configuration Manager 2012 sees the UNIX/Linux clients as just another client, the reports you are using today for your Windows based clients are the same that you use for the UNIX/Linux clients.

Client Architecture

Each UNIX/Linux distribution has its own set of client installation files which can be downloaded from our download centre, as UNIX/Linux versions can have different characteristics that we need to interact with (note the orange layer in the diagram below).

You’ll also note that we are installing a CIM server called NanoWbem (Opensourced by Microsoft through Opengroup http://www.opengroup.org/software/omi) along with the client itself to provide the WMI-like functionality we are used to with a Windows client. One thing to be aware of is that the CIM server we are installing with the Configuration Manager 2012 SP1 client is different to the CIM server that the System Center Operations Manager client installs.

The UNIX/Linux client talks back to the Configuration Manager 2012 SP1 infrastructure over HTTP or HTTPS. Content downloads are also performed over the same protocol (so there is no SMB client requirement on your UNIX/Linux server), but as the UNIX/Linux clients are treated as workgroup clients you need to ensure the network access account is configured. The UNIX/Linux client will then use the network access account to authenticate with the distribution point when downloading content.

Why do I care as a ConfigMgr administrator?

A simple answer to the ‘Why do I care’ argument is – you own ConfigMgr and, as a ConfigMgr administrator, you have extensive experience managing Windows systems so why not extend that capability to managing UNIX and Linux systems? In the current IT environments that exist in most organizations today, being able to show additional value with existing resources can only be a good thing! One question that may be on your mind is whether you have to learn UNIX and Linux to effectively manage those systems through ConfigMgr. There will be some learning that will be required but in no way do you need to be a full UNIX or Linux administrator to effectively leverage ConfigMgr to manage these systems. After all, the management concepts are similar – the only real difference is implementing the management. Let me say at the outset that I in no way consider myself an expert – or even proficient – at UNIX and Linux administration – but I am very proficient at ConfigMgr so with the ConfigMgr client am able to make UNIX and Linux sing! As you will soon see, the ConfigMgr client on a UNIX or Linux system is little different from the ConfigMgr client on a Windows system. The biggest hurdle is getting familiar enough with the UNIX or Linux system to know how to operate effectively. I’ll try to help you with that with a few hints below.

Other reasons that you may care to manage UNIX and Linux systems is the unified view this will bring to systems in your environment. Now not only can you deliver metrics on your Windows systems but UNIX and Linux as well!

The Unix and Linux client

The UNIX and Linux client is not distributed with the ConfigMgr 2012 SP1 or even the cumulative update 2 source. The client can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=36212. The screenshot below shows the UNIX and Linux files all downloaded into the same directory

Notice that there are separate files for some of the supported UNIX and Linux versions but not all supported platforms have their own unique installation files. Why? Good question. The answer is found in the last couple of files called the Universal installer. This Universal installer supports installing the ConfigMgr client on all supported Linux platforms – for the UNIX platforms you should continue using the unique files for each distribution. In the list of files you see for specific files for some Linux distributions – such SLES and RedHat. These files are the original release of the ConfigMgr client and not the updated one provided by the Universal client installation.

Working with UNIX and Linux 
As already stated, I by no means consider myself a UNIX or Linux guru. In fact, working with UNIX and Linux was quite interesting for me. It’s quite unusual for me to sit in front of a computer and be totally lost! J If you are new to UNIX and Linux, you likely will find yourself feeling exactly that way! Let me try to help.

In my lab I run UNIX and Linux systems as Hyper-V virtual machines – and that was the first problem. When I loaded up my first Linux environment my natural tendency was to grab the mouse to try and get things configured. Alas, the mouse didn’t work. I quickly became frustrated because I couldn’t figure out how to navigate with keyboard to even get into a terminal window. Add to this that I didn’t have any network access because the Linux distribution I chose didn’t support the Hyper-V integration components! Argghhhh. Never a quitter I struck out with my trusty Bing search skills and quickly found my way. A summary of those tips below.

1. If you choose a distribution that does not have native support for the Hyper-V integration components you can add them by downloading and installing them to Linux manually. The files and instructions can be found at the links below.

http://www.microsoft.com/en-us/download/details.aspx?id=11674 (Windows 2008 R2 Hyper-V Integration Components)

http://social.technet.microsoft.com/Forums/windowsserver/en-US/0d2c5fa8-682c-4f5d-9fe7-388dd80a7e06/simplified-instructions-for-installing-the-linux-integration-components-into-hyperv-virtual (a nice write up on how to install mouse drivers into a Linux distribution)

NOTE: If you let a native UNIX or Linux person see you using a mouse they will laugh at you! J

2. If your distribution doesn’t support the native integration components for Hyper-V then likely networking won’t work. You can generally get around this by leveraging a Hyper-V legacy NIC.

3. On SUSE Linux, YaST is a fantastic utility for configuring the NIC – as you will see below. Other distributions have their own tools and the generic ones generally work as well. IfConfig is another tool useful for configuring the network – more on that one below as well. Persisting IfConfig settings requires editing the interfaces file as described in http://www.ubuntugeek.com/ubuntu-networking-configuration-using-command-line.html.

4. Putty is your friend! Just like you want to remotely manage Windows systems, you want to do the same with UNIX and Linux systems. Putty allows you to remotely connect to a UNIX or Linux system but only from a command line. Putty is available at http://www.putty.org/

5. WinSCP makes Windows admins feel at home. One of the biggest challenges I faced was figuring out how to connect my UNIX or Linux system to my Windows environment to copy and manipulate files. The instructions for setting up the client will give you some insight on how to do that but when it comes to browsing the system to view log files, understanding the client installation location and more, I found it quite handy to have a tool like WinSCP that will allow seamlessly moving files between a Windows and UNIX or Linux environment. WinSCIP is available at http://winscp.net/eng/index.php.

6. Text editor – VI – get used to it if editing on Linux console. WinSCP will help but unless running root you must use ‘sudo’ (as you will see soon) to save info in some cases – and it’s just easier to use VI. A good shortcut doc to get you started navigating vi is http://linuxservertutorials.blogspot.com/2008/11/ubuntu-command-line-text-editor.html.

The best way to understand how to use these tools to navigate UNIX or Linux is to see it in action – so let’s start from the beginning. In my lab I have two virtual machines – one running SUSE Enterprise Linux and the other running Ubuntu 12.04. The first step with these VM’s is to confirm they are up and running on the network. If you are running in a VM and if your distribution doesn’t recognize the native NIC (such as when running in a Hyper-V environment with a distribution that does not have the integration components included) then you may need to use a legacy NIC in order configure networking.

Let’s start by working through configuring network access for my SUSE Enterprise Linux client. Note that in my lab with the SUSE Enterprise Linux client I am logging on with root – which makes things a bit easier to configure but is also less secure. For the Ubuntu 12.04 system I’ll show configuration running as a non-root account.

With SUSE Enterprise Linux installed, login as root.

To configure networking (and many other things) in SUSE Linux, YaST is a fantastic tool! There is a GUI based version of YaST and a command line version of YaST. Since we are aspiring to be expert UNIX and Linux administrators, we will go with the command line version! J It’s also really easy to use in command line form, which helps. Launch YaST from the command line by typing ‘YaST’ and navigate to configure the network as shown in the next few slides. NOTE: Navigating YaST is easily done with <tab> and <shift><tab>.

Select Network Devices > Network Card

Make sure you use the Traditional method of setup – the other will seem to work but fail when committing changes if you don’t have the required components installed in your setup.

In this case I have two Network Cards – one that is the default but that doesn’t work for me in this setup since I don’t have the Hyper-V integration components – the other was added when I added the Legacy Hyper-V NIC.

To configure the NIC simply navigate to Edit on the NIC you want to configure and fill in the details for the options. The IP address and subnet mask, along with the hostname and DNS information will be most common. Once done, commit your changes and test to ensure you can ping another system on your network.

So now the network is configured in SUSE Linux using YaST. With this done most likely you don’t need to keep the VM up and running any longer – we will connect to it with a couple of extra tools shortly. Now, let’s configure the network on the Ubuntu 12.04 system.

For the Ubuntu system I will login as a non-root account.

YaST does not exist on Ubuntu so instead we will use a more traditional means of configuring the network. This approach should work on most, if not all, Linux distributions.

To get the network configured for a one time use we can use IfConfig from the command line as shown.

Interesting!  Notice the permission denied messages! Remember what I mentioned about logging in with a non-root account? That’s why I don’t have permissions to make this change. I can fix this quite easily by simply adding the ‘sudo’ command at the beginning of the command line.

And that’s it – network is configured as we see by the fact the system is now able to ping other devices on the network.

OK, so your actually not quite done. As long as you leave this session up and running, all is good. If you reboot though the network config is lost. So how do you configure the system to persist your network configuration? It’s actually not that hard but will require that we leverage a text editor and also launch that test editor with administrative permissions. I’ll also use this as an opportunity to explain the config a bit more.

The configuration file we need to modify is /etc/network/interfaces. By opening this file you can view the config but won’t be able to save it unless your editor is launched using sudo. The most ubiquitious test editor on Linux is VI so we can launch VI and edit our file as follows

I’ll select to Edit anyway and we get the file. In my case the configuration has already been added. A couple of things to note here. First, there are additional options for the network config vs. what I showed in the initial example. Second, there are very likely multiple interfaces on the system. You will need to reference and config each one appropriately. The tag, such as eth0, eth2, lo, will identify the config for each specific adapter.

NOTE: I find using VI to be utterly and unnecessarily confusing but once you get accustomed to the basic editing functions, it’s actually not that bad. The key is whether you are in command or authoring mode. Though nor exhaustive, the documentation at http://linuxservertutorials.blogspot.com/2008/11/ubuntu-command-line-text-editor.html is a great help and should be enough to get you to where you can edit and save the configurations you need in this file.

Edit the file as needed – the documentation at http://www.ubuntugeek.com/ubuntu-networking-configuration-using-command-line.html 
is helpful for this. After you save if you want to ensure the network adapter configuration information is persisted, reboot and then run the configuration tool to validate, as shown.

OK, NOW you are all done with network configuration. Fun, huh? If we have full network connectivity to our VM’s then at this point there should be no need to maintain an open connection to your VM’s. I have closed my two sessions and will use two other tools to remotely manage my machines – Putty and WinSCP. I find both indespensible – for different reasons. We will use Putty now and WinSCP will come into focus when we begin discussing the client install.

Much like an RDP session in the Windows world, Putty allows remote connect to the command line of Linux machines. I will launch Putty and connect to as many systems as I need. From this point forward I will just use one of my VM’s because the steps forward are identical for whatever UNIX or Linux distribution you may be using.

After I specify the connection information I get connected to the remote system, supply my credentials and I’m in – just as if I were connected to the system locally.

Client Installation

Finally we are at the place where we can begin the client installation. As mentioned earlier, the universal client is the one we want to install on any supported Linux distribution. It has the latest code base and applies across all supported platforms, even when a named installer also exists (shown previously).

There is excellent step-by-step documentation for installing the ConfigMgr UNIX and Linux client. The process is to create a temporary directory, mount the client files from a remote Windows share, change the install mode so installation is allowed, install the client and then cleanup/explore. We will go through these steps here as well but I’ll also use this process to introduce WinSCP.

The first thing to do is create the temporary folder to hold our client files.

With the temporary directory made, the next step in would be to mount the client files from a remote Windows share using the command line below.

mount -t cifs -o username=<User Name>,password=<password> //<Windows computer Name>/<Client File Share> /tmp/CCMClient

This works but I see this as a great opportunity to introduce WinSCP which is an explorer like utility that is perfect for moving files between Windows systems and UNIX or Linux. So let’s use WinSCP to move the client files into the temporary directory. WinSCP is available at http://www.winscp.net.

Launch WinSCP and supply your connection details and credentials.

The connection establishes and opens into an explorer like view. The view here may be different depending on the options chosen during setup.

We will copy our installation files to the /tmp/CCMClient folder using copy & paste.

So the files are now copies and we are ready to continue with the install. So this was just a simple look at WinSCP but you hopefully already see how convenient it is. You can use WinSCP to edit text files, copy the ConfigMgr log file from the UNIX or Linux system to the Windows system to view with CMTrace and more.

With the files copied we will execute the command lines that will ready the Linux system to allow the install and then to perform the client install.

The client install completes – notice the highlighted parts. So what exactly is OMI? OMI is UNIX and Linux equivalent of WMI that Windows administrators will already find familiar. Just like the Windows ConfigMgr client, the UNIX and Linux client makes use of WMI/OMI for storing information for the client and retrieving hardware inventory. We will see this shortly.

So that’s it. The client is installed. If the client is able to communicate properly we will see it show up in the ConfigMgr 2012 SP1 console under devices. Depending on configuration you may need to approve the client. Once hardware inventory completes you will be able to see that reflected in resource explorer for the client, as shown.

If you want to practice with software distribution, that is done via packages. I build a test package using the OpsMgr UNIX or Linux agent.

Just like the Windows client, all of the activity on the UNIX or Linux client can be tracked in the log file. Different from the Windows client, all of the functions of the UNIX or Linux client are combined in a single log. Also, UNIX and Linux clients default to only show ‘Warning’ log entries. This is a different experience from the Windows client and I’ve seen many questions raised on how to read the log and

Interpret meaning. The answer is simple – add more verbosity to the log and it will then read very similar to a Windows client log file.

There are four levels of logging available – error, warning (default), info and trace. Trace is the most verbose level of logging you can have. Like verbose and debug logging, trace logging on a UNIX or Linux system is listed as something that should only be used for troubleshooting. To me, the extra level of logging provided by verbose/debug and trace makes it sufficiently valuable that I leave it on all the time – so if there is a problem I hopefully won’t need to go back and enable logging and again reproduce the issue. Each person will need to decide this for themselves. The most common argument for disabling verbose/debug or trace level logging is to prevent putting extra load on the system. For any modern device the extra load imposed by additional logging will not even be noticeable and provides great value.

To change the log level we will leverage WinSCP again and open the scxcm.conf file at /opt/microsoft/configmgr/etc/

With this level of logging in place we will restart the client and then take a look at the log. The commands to restart and interact with the client to trigger a policy or hardware inventory cycle are below.

Start, Stop, Restart 
/etc/init d/ccmexecd start 
/etc/init d/ccmexecd stop 
/etc/init d/ccmexecd restart

Trigger Client Actions 
/opt/microsoft/configmgr/bin/ccmexec –rs policy 
/opt/microsoft/configmgr/bin/ccmexec –rs hinv

To take a look at the log file generated in CMTrace we use WinSCP to move the log file to our Windows system and then open in CMTrace.

OK, so one last thing to discuss. I mentioned earlier that the UNIX and Linux client makes use of OMI which is a WMI equivalent for UNIX and Linux. The beauty of this is that this allows ConfigMgr administrators who are already familiar with WMI to be able to apply those skills to the UNIX and Linux client. If we take a look at the ConfigMgr client install folder with WinSCP we will see some familiar territory. Note the highlighted area. If you have spent any time in WMI on a Windows client you will recognize these as WMI namespaces. The ccm and invagt namespace are ConfigMgr specific and the CIMV2 namespace is a system namespace ConfigMgr leverages for pulling inventory.

If we look in the cimv2 namespace we see familiar classes. Not all the classes we would see on a Windows machine – not by a long stretch – but familiar ones nonetheless – and the information in these classes is what we will collect with hardware inventory and what you will see in the console.

If we open a couple of these we will see the data that resides in each. Note that not every potential entry contains a value – same as when viewing this information on a Windows client.

And one more…

And that’s it – that’s the UNIX and Linux client – definitely worth taking a look at and hopefully this helps you along the process. One last thing to mention. As already pointed out, the UNIX and Linux client come as separate downloads. They are not part of the ConfigMgr 2012 media and, accordingly, there is no inbuilt mechanism to install the UNIX or Linux client. It’s really up to you to decide how best to do so – script, manually, whatever. Wouldn’t it be cool if we could do the install very similar to the way we are able to push the client with ConfigMgr? Hmmm…well, glad you think so. One of my colleagues, Neil Peterson, has put together a blog post on using System Center Orchestrator to do just that. The blog post is available athttp://blogs.technet.com/b/neilp/archive/2012/10/17/system-center-2012-automating-configuration-manager-client-deployment-to-linux-systems.aspx. If you haven’t started looking at Orchestrator to automate your routine IT processes, you should. Orchestrator is very familiar territory for those familiar with task sequencing and something that should be in the back pocket of every ConfigMgr administrator!

What’s on your mind? Talk back to me by leaving a comment below.