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

□ 개요
o Adobe社는 최근 타겟형 공격에 악용된 Flash Player 취약점을 해결한 보안 업데이트를 발표[1]
o 낮은 버전 사용자는 악성코드 감염에 취약할 수 있으므로 해결방안에 따라 최신버전으로 업데이트 권고
 
□ 설명
o Adobe Flash Player의 26개 취약점에 대한 보안 업데이트를 발표[1]
   · 임의코드 실행으로 이어질 수 있는 Use-Ater-Free 취약점(CVE-2016-7855)
 
□ 영향 받는 소프트웨어
o Adobe Flash Player

 
□ 해결 방안
o Adobe Flash Player 사용자
- 윈도우즈, 맥 환경의 Adobe Flash Player desktop runtime 사용자는 23.0.0.205 버전으로 업데이트 적용
   · Adobe Flash Player Download Center(http://www.adobe.com/go/getflash)에 방문하여 최신 버전을 설치하거나, 자동 업데이트를 이용하여 업그레이드
- 리눅스 환경의 Adobe Flash Player 사용자는 11.2.202.643 버전으로 업데이트 적용
- Windows 10 및 Windows 8.1에서 구글 크롬, Microsoft Edge, 인터넷 익스플로러 11에 Adobe Flash Player를 설치한 사용자는 자동으로 최신 업데이트가 적용
   · 그 외 사용자는 Adobe Flash Player Download Center(http://www.adobe.com/go/getflash)에 방문하여 최신 버전 설치
 
□ 용어 정리
o Use-After-Free 취약점 : 소프트웨어 구현 시 동적 혹은 정적으로 할당된 메모리를 해제했음에도 불구하고 이를 계속 참조(사용)하여 발생하는 취약점
 
□ 기타 문의사항
o 한국인터넷진흥원 인터넷침해대응센터: 국번없이 118
 
[참고사이트]
[1] https://helpx.adobe.com/security/products/flash-player/apsb16-36.html

For many people, the idea of using Linux as a low-cost network management platform can be highly seductive. As the argument goes, even the most rudimentary Linux distributions include the components that are needed to build a modest management console, with Net-SNMP extracting management information from devices on the network, RRDtool storing and graphing the collected data, and one of the many Linux-based network management packages providing a Web-based point-and-click interface to the system as a whole.

For the most part, this approach can even work fairly well for basic monitoring tasks, although it also has its limits. In particular, most network devices do not publish all of their available management data through SNMP, and getting to the additional data typically requires the use of an alternative management interface.

This can even be a challenge with Linux itself, since many of the system variables in the /proc filesystem are not published over SNMP by default, while many of the web and email application servers that are commonly used with Linux do not have any SNMP interfaces at all. If you need to capture any of that data, you'll need to find a way to extract it from log files or process-management tools, and then import it into your management station through a secondary interface.

But while this can be tedious for systems like Linux, it's a huge problem for the systems and services that use Windows Management Instrumentation (WMI) as their primary management subsystem, since there has not historically been any way to query WMI from Linux directly (see sidebar at right). Instead, administrators who have committed themselves to Linux-based management consoles have had to rely on gateway or proxy technologies that query Windows systems for the desired data on behalf of the management station. For Windows-heavy networks, the path of least resistance has simply been to use Windows-based management platforms that can access the data directly, and forgo the Linux management station altogether.

In practice, there are a variety of ways to pull WMI data into Linux-based management tools, many of which are discussed throughout the remainder of this article. However, while most of these tools are useful for extracting some degree of data from WMI, they also have unique operating considerations which can affect their utility in unexpected ways. For example, some of the solutions require new software to be installed at the management station, on a gateway device, or at each of the Windows hosts that will be monitored, and some of them may require modifications to the security permissions on some of those systems as well. Similarly, the different solutions can expose widely varying amounts of data, which not only determines the functionality of a particular package, but also introduces additional security considerations.

The Windows SNMP Agent

The simplest way to get data from WMI into Linux management stations is to go through the SNMP agent that is included with the Windows operating system, although there are some significant limits on the information that is available through this interface. More accurately, the principle restriction with the Windows SNMP agent is that it does not provide much in the way of Windows-specific data.

For example, the HOST-RESOURCE-MIB defines basic CPU utilization metrics that shows the average processor utilization levels for the last minute of activity, but that is all it provides. The problem here is that the standardized data just isn't very useful, especially compared to the CPU utilization data from the WMI performance counters which tells us how many tasks are currently in the process queue, how much of the load is from system tasks versus user tasks, and much more. Unfortunately, none of the interesting and useful data is available through the native SNMP agent.

The good news is that some third parties have stepped up to fill this void, and it's possible to get at the interesting data via SNMP by using aftermarket extensions. The biggest name in this space is SNMP Informant, which is the brand name for a series of products ranging from a basic freeware extension that exposes a limited amount of operating system data all the way up to a commercial multi-extension that exposes huge tracts of data from the operating system and add-on packages like Microsoft Exchange and SQL Server (among others).

SNMP Informant works by strongly data-typing the core performance counter objects, and then mapping predefined OIDs against those objects, thereby allowing administrators to make explicit and clean references to system-level objects in a consistent and reliable way. However, the downside to this approach is that every OID in the extension must be predefined, and SNMP Informant only focuses on several very important areas but does not attempt to expose the entire WMI subsystem to SNMP. This means that if you need to access performance counters or some other piece of WMI data that SNMP Informant does not already publish, you have to look elsewhere.

One interesting extension that has appeared in this space recently is the freeware SnmpTools, which purports to allow mapping administrator-defined OIDs to a variety of data sources, including hard-coded string values, dynamic performance counter objects in WMI, and even dynamic output from text-based scripts and programs. Although the WMI-specific part of the extension is limited to performance counter objects, it's theoretically possible to query other parts of the subsystem through the use of a local script and return the data through the command interface.

Another angle on this space is that many of the server hardware vendors provide their own SNMP extensions for Windows as a way to publish management information about the server hardware. When added to the other extensions discussed above, this can really round out the data that is available through the stock SNMP agent.

The general downside to this class of tools is that they have to be installed on every Windows system, since they extend the SNMP agent on the local host. However, they do not require any new software on the Linux management station, since they tend to work seamlessly with existing SNMP interfaces. These technologies also do not typically require any significant changes to existing security models, since the native SNMP agent's authentication services will continue to be used. On the other hand, the lack of encryption in SNMP means that adding extensions that publish more data will result in more data being available for eavesdroppers to discover.

WBEM and WMI

Just as SNMP is generally the preferred management technology for Linux systems to use when querying Windows devices, the other end of the spectrum has it that WMI is the most natural technology to use when managing Windows systems and services. Thus, if Windows cannot be made to speak SNMP adequately, another option is to make Linux speak WMI. But as stated in the introduction, WMI has not historically been available to Linux systems due to a variety of technological issues. However, it has long been possible to make Linux systems speak WBEM, and since the principle difference between WBEM and WMI is the transfer protocol in use (again, see sidebar), all that's really needed to expose WMI to Linux is a WBEM listener for Windows and a WBEM client for Linux.

There are a couple of options for running a WBEM listener on Windows. For one, the Open Group has an open-source WBEM implementation called OpenPegasus with a standalone WBEM-to-WMI gateway component called WMI Mapper, which listens for incoming HTTP/WBEM queries on the standardized ports, processes the requests as WMI queries on the destination system, and then returns the answer data to the original requester. Unfortunately, WMI Mapper is only available from the OpenPegasus web site as raw source code, which can be an issue for many organizations. However, the HP Systems Insight Manager server-management toolkit provides a prebuilt version of WMI Mapper as a separate downloadable add-on package.

Another option for adding WBEM capabilities to Windows comes from the IBM Systems Director server-management suite. Specifically, IBM Systems Director provides Windows agents with comprehensive WBEM implementation that can also be used to query WMI on the local system. These agents can carry a lot of overhead, but they can also add a tremendous amount of manageability to their host systems. Furthermore, organizations who are thinking about using WBEM on their other platforms can look at the Director agents as a way to get a consistent WBEM interface on multiple platforms simultaneously.

Once one of these packages have been installed and configured, the only remaining requirement is a WBEM client for Linux that can generate queries and return formatted data to the management console. There are a handful of WBEM toolkits available for Linux (including tools that are included in the aforementioned WBEM-based server-management consoles), but one simple utility for this purpose is wbemcli from the Standards-Based Linux Instrumentation (SBLIM) suite, which allows you to generate requests for named resources and apply basic formatting to the response data using command line options. Some of the common Linux distributions already include the sblim-wbemcli package, but it can also be downloaded from sourceforge.

There is also the somewhat-recent option of running a WMI client directly on Linux, and bypassing all of the intermediate technologies altogether. Specifically, the Linux-based Zenoss management platform provides a utility called wmic, which uses the Samba4 libraries to access Windows and interact with WMI directly. Using the wmic utility, it's possible to retrieve just about any object from anywhere in WMI (the author uses it togenerate custom graphs from Everest sensor readings stored in WMI), although you have to generate the queries using the WQL (WMI Query Language, which is very similar to SQL). wmic is packaged as a separate program in some Linux distributions, but is also included in the open-source version of Zenoss Core.

Of all the options for getting management data out of WMI, wmic is clearly the simplest and cleanest way to do it. However, it's also important to recognize that wmic is only useful for querying WMI, and it is unable to engage or manipulate WMI objects. If you need that level of access then one of the WBEM approaches is going to be your only option for now. Another advantage that WBEM has over wmic is the fact that you can deploy WBEM servers on your Linux systems so that all of your devices are presenting fairly consistent high-level management interfaces. This is not something that should be embraced casually, but it is an important and compelling opportunity that should not be dismissed blithely either.

In terms of deployment, the Director Agent is the only technology mentioned that requires new software to be installed on the Windows systems for the data to be accessible to Linux management consoles. The OpenPegasus/HP WMI Mapper gateway is able to issue WMI requests for objects on local and remote Windows systems, so it only needs to be installed on a single gateway device. wmicdoes not need any new software on any Windows device. All of these solutions require client-side software of some kind on the Linux management console.

All of these solutions also require changes to Windows' security permissions in order to function, particularly in the areas of WMI object permissions, and in the case of wmic there are likely to be changes to DCOM permissions as well (the default Windows permissions only allow administrative users to issue remote queries, which is not viable for most networks).

Remote Command Execution

If SNMP and WBEM/WMI all prove to be unsatisfactory for some reason, then it's time to explore alternative management interfaces. Luckily, this tends to be fairly straightforward on Linux-based management systems; everything uses the command-line to move data around already, so calling an alternative management tool is theoretically as simple as replacing the snmpget command with an appropriate substitute, and ensuring that properly-formatted response strings are generated.

As was alluded to in the introduction, this kind of alternative command model is sometimes needed in order to pull interesting data from the local Linux system itself. For example, if you need to routinely extract management data from a local email server's log file, then you will probably need to execute an arbitrary script that returns the required data and then pass the formatted results back to the management station. By extension, if you need to gather this data from all of the Linux hosts on your network, then one option worth considering is to simply distribute the script to each of them, and then use a local program to execute the remote scripts as needed. This same model can also be made to work with Windows, and in fact is actively embraced by some popular management toolkits.

However, this model can also be slow, resource-intensive, and even risky, depending on how it is implemented. Simply put, it's expensive to spawn command processes, and twice as expensive to spawn them locally and remotely. It would be foolish to use this model when some other lighter option was available. On the other hand, if you need to perform a computationally- or I/O-intensive process in order to obtain the desired information (such as parsing through open log files, or gathering multiple pieces of data for comparison purposes) then it can often be faster and cheaper to execute the command on the remote host instead of issuing multiple discrete queries across the network and performing the calculations locally.

As for making this work, modern versions of Windows usually include most of the tools that are needed, although some assembly is often required, with greater amounts of work being needed for progressively older versions of the operating system. For example, modern versions of Windows include the Windows Script Host interpreter and the character-based cscript.exe front-end, which cumulatively allow you to execute VBScript files from the command line. Even more recently, the Windows PowerShell also provides a scriptable environment that is accessible directly. Either of these tools can be used to query and even manipulate WMI objects, including WMI objects on other Windows hosts across a network.

Figure 4

There are also multiple options available for executing these scripts from remote. One option here is to install an SSH server on the Windows host, and then use ssh hostname remote-command from the Linux console to execute the desired script, just like you would on UNIX systems. Windows systems with Subsystem for UNIX Applications (SUA)/Services for UNIX (SFU) can download premade SSH servers from Interop Systems. Alternatively, there are multiple SSH servers for Windows available that are based on Cygwin if you prefer to use that environment.

As another option, the Nagios management platform provides a remote-command interface called NRPE that is essentially a client-server protocol for executing predefined commands. In this model, target systems are setup as NRPE servers, while the management station runs an NRPE client. Commands are defined in a configuration file at each server, and the client connects to the server and instructs it to execute one of those commands, with any additional parameters being supplied in the request. If the command is known to the server, it executes the request and returns the response data, then closes the connection. NRPE is simpler to setup than SSH, and it is also arguably more secure given that the server cannot run arbitrary programs. There is also a prebuilt NRPE server for Windows available.

Naturally, the ramifications for this class of technology can be immense. On the security front, their whole raison d'être is to facilitate remote command-level access to your Windows servers, which frankly should be enough to give anyone pause. As for deployment, these tools require additional software or scripts on the Windows hosts, but since the scripting tools can perform WMI queries over the network you really only need the executables to be installed on one specific server, which can then act as a proxy for all of the other Windows hosts that it has access to (this will require that the scripts have a hostname argument, obviously). Some software may also be required on the Linux management station, such as the NRPE client, or wrapper scripts that call the preferred tool and dispose of the response data.

Administrators who are interested in pursuing remote-command execution techniques should study some of the scripts hosted on monitoringexchange.org, which includes a variety of VBScript files for extracting data from WMI. Some of these scripts can be useful for some of the other technologies mentioned earlier as well.

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.