Port 25: The Open Source Community at Microsoft : Community, Technical Analysis

Technical Analysis: Apache with mod_auth_kerb and Windows Server

jcannon — Fri, 25 Jan 2008 21:58:00 GMT

Abstract: The Apache authentication module mod_auth_kerb allows Apache to authenticate users against a Kerberos KDC including one from ActiveDirectory. Kerberos itself can be fairly complex to set up. This guide will attempt to show the specific steps required to make this possible as well as discuss security limitations specific to the interoperability matters. This guide assumes a basic understanding of Kerberos V and that the Active Directory domain controller is properly configured prior to starting this process.

Note: This paper represents testing and documentation in a lab environment. User Account Control (UAC) is an essential security component to Windows and Microsoft does not recommend turning off UAC in production environments.

Systems Manageability Part 7 - Log Management and Analysis

kishi — Tue, 07 Aug 2007 15:57:00 GMT

Level-Set – Log Management: This section includes open-source technology directed primarily on host-based logging, log file rotation and log file analysis. Many of these tools are very common free and open-source software tools that are distributed and preconfigured with most of the major Linux systems, including major vendors such as RedHat and Novell.

I. Logrotate

Logrotate is a very popular application utilized in a number of Linux systems, including all RedHat and SUSE based systems. The logrotate utility typically runs periodically via cron, a task scheduling application. The utility will read a configuration file (/etc/logrotate.conf), and archive and compress log files according to the configuration. Administrators can configure when log files should be rotated based on age and size, and how long backlogs should be maintained. Older archived log files can then be swapped out and replaced with newer archives.

II. Syslogd and klogd

Typical Linux systems utilize a syslog daemon to capture log messages from userspace applications and write them to text-based log files or send them to a logging host over the network. The syslogd daemon is often accompanied by a klogd application which is designed to capture and log kernel messages.

The behavior of the syslog daemon can be configured via the /etc/syslog.conf configuration file. All messages captured by syslog are categorized by facility and priority. Messages can then be sent to particular log files or logging hosts, or dropped completely based on their facility and priority attributes.

Facilities

Priorities

- auth or security

- authpriv

- cron

- daemon

- kern

- lpr

- mail

- mark

- news

- syslog

- user

- uucp

- local0 through local7

- debug

- info

- notice

- warning or warn

- err or error

- error

- crit

- alert

- emerg or panic

List of syslog facilities and priorities.

III. Syslog-ng

The syslog-ng application aims to be an enhanced drop-in replacement for the traditional syslog daemon. It provides many of the same features of the standard syslog daemon, but includes additional features such as advanced message filtering based on content, remote logging via UDP or TCP, and the ability to write log files to a database such as MySQL or PostgreSQL. More recent SUSE-based systems such as SLES10 have switched to syslog-ng as the default syslog server.

IV. Viewing Logs

Most log files on a Linux system are stored in plain-text, which means they can be viewed and parsed using a number of different command-line tools. Typical utilities such as tail, head, grep, cat, less, more, sed and awk can be used to view and filter log messages via the command line.

There are also a myriad of utilities designed to parse and view log files via a GUI or web browser. Some utilities are even designed to handle specific log formats, such as those generated by Linux’s Netfilter firewall subsystem.

GNOME System Log Viewer

The GNOME system includes a GTK-based system log viewing application that displays system logs via the GUI.

YaST System Log Module

SUSE-based systems using YaST typically include a module called View System Log (called internally as view_anymsg). Similar to the GNOME System Log viewer, the YaST module allows an administrator to view many of the various system logs without using the command-line.

V. Log Analysis

LogWatch

The logwatch utility is designed to parse system logs and located any entries that might indicate security threat or system failure and send an email report to a designated address. Logwatch is distributed with RedHat Enterprise Linux systems. The following is an excerpt from the RPM description:

“LogWatch is a customizable log analysis system. LogWatch parses through your system's logs for a given period of time and creates a report analyzing areas that you specify, in as much detail as you require. LogWatch is easy to use and claims that it will work right out of the package on almost all systems. Note that LogWatch now analyzes Samba logs.”

LogWatch is typically executed periodically via cron, a task scheduling application.

LogCheck

The logcheck utility is a part of the Sentry Tools project that also includes portsentry, a utility designed to detect port scans. Similar to the LogWatch utility, the software is designed to parse system log files, find log entries that may indicate security problems and send an email to a preconfigured address. Also similar to the LogWatch utility, logcheck relies on the standard cron utility to be periodically executed.

That does it for Log Management and Analysis section. We have one last blog to go and certainly hope that you found the information we have captured for you useful. If you’re running any special toolsets or customizable scripts for log management and analysis and would like to share your experience with us, please send us your feedback and as always, THANK YOU for tuning into Port25.

Systems Manageability Part 3 - Provisioning and Deployment

kishi — Thu, 03 May 2007 17:29:00 GMT

I want to start this blog with a note of Thanks to Ajay Mungara, the Manageability Developer Community Manager from Intel and “einhverfr”, both of whom gave some very constructive feedback on the previous blog. In the next six blogs to follow, including this one, I will do a “deep-dive” into the six specific areas we covered under the “Systems Manageability” ontology.

Let’s start this blog with the first of the six categories from the ontology - “Deployment and Provisioning”

Level-Set: Deployment and Provisioning as we understand it, encompasses all tasks related to the initial installation of an operating system on remote system, as well as post-installation of software on a remote system. Much of these toolsets are geared toward automated system provisioning and cloning. There’s lots of different tools out there that can be used but we have focused on the most popular ones, namely Kickstart, Autoyast, “Bare-Metal” provisioning and RedHat Network. In the paragraphs to follow, we have attempted to lay out our understanding of these tools after using them in the OSSL:

I.KICKSTART: is an automated installation utility for RedHat-based systems, including Fedora Core and RHEL based systems. Kickstart software requires the creation of a configuration file (similar to an “answer file” in Windows lingo) which contains all the information the installation program will require to install the operating system. The configuration file and all the RPM software packages are typically kept on a remote server such as a HTTP or FTP. The location of the Kickstart configuration file is typically passed to the kernel at boot time. For example, once the bootloader (GRUB, LILO) loads, the user is often presented with a “boot:” prompt that allows the user to pass arguments to the kernel. To load a kickstart configuration file from a remote server one would type the following:

boot: linux ks=http://<server>/location/of/kickstart.cfg

The administrator can then create multiple Kickstart configuration files for different configurations. With the addition of a PXE-based server, much of the provisioning process can be automated. A Kickstart configuration file is simply a text file, which can be created and edited manually with any text-editor. A GUI-based Kickstart file creation program called system-config-kickstart is also available from the Fedora and RHEL distributions. Both kickstart and autoYaST provide the ability to run arbitrary commands during the post-installation phase. This allows administrators to run individual commands, or entire shell scripts to automate any post installation tasks that may be required. RedHat provides a GUI-based tool to assist one in building a kickstart configuration , however in practice it is very easy to customize the configuration file by hand. The ability to run shell commands via the post-configuration phase is simple yet extremely powerful.

II. AutoYaST: is another automated installation utility, similar to RedHat’s Kickstart utility, but used primarily with SUSE-based systems. Novell provides a YaST2 module for autoYaST, which is a GUI tool that can be used to create an autoYaST configuration file – also similar to RedHat’s system-config-kickstart utility. Many of the same rules and procedures used with the kickstart utility also apply to autoYaST. Administrators that need to deploy SUSE clients or servers can create any number of autoYaST configuration files to fit a particular system profile. These can then be used to automate the installation of a SUSE system over a network. When combined with PXE/DHCP setup administrators can deploy and start a SUSE install without using any physical media (i.e. an installation CD/DVD).

III. Bare-Metal Provisioning: Automated deployment tools such as Kickstart and Autoyast support system provisioning via HTTP, (T)FTP and NFS. Completely automated installations can also be configured using the Pre-Execution Environment (PXE), DHCP, tftp and kickstart or autoyast. By automating the boot process, it no longer becomes necessary to manually initialize the installation process via a CDROM or other bootable medium.

Many cluster deployment solutions utilize these very same technologies to deploy large numbers of nodes in a very short time. ROCKS, for example, automates the booting and (re)deployment cluster nodes on the network using PXE, DHCP and kickstart, a process that can sometimes require less than 10-minutes for a single node. Proprietary tools such as CSM, IBM’s cluster management software, also utilizes PXE, DHCP and kickstart or autoYaST to (re)provision cluster nodes as needed.

Configuring a PXE Server for Automated Installations: There are two common utilities one may use to configure a PXE server on Linux. Testing for this scenario was done using a RedHat based system. Therefore some aspects of the following descriptions, such as locations of configuration files, will be RedHat-centric. The general necessity of the configuration and the components, however, are not distribution specific.

pxeos – This utility can be used to configure operating system descriptions within the PXE boot files. Operating system descriptions include the OS name, the protocol used to obtain the OS files (HTTP, FTP, NFS) and the full URI and path to the installation files.
system-config-netboot – The system-config-netboot utility is a graphical application that can perform many of the same tasks as the pxeos utility.

Configuring DHCP: The DHCP daemon can be configured via the /etc/dhcpd.conf file. Those options that are specific to allowing PXE boot clients are listed below.

allow bootp;
class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
filename "linux-install/pxelinux.0";
}

Configuring TFTP: The TFTP daemon must first be enabled via xinetd super daemon. The following configuration is added to /etc/xinetd.conf, or sometimes /etc/xinetd.d/tftp, depending on the distribution:

service tftp
{
        disable                 = no
        port                   = 69
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /tftpboot
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}
TFTP Configuration in xinetd.conf
The directory /tftpboot/linux-install is the default used by the system-config-netboot configuration tool. The directory contains kernels and the necessary configuration files required to boot a system and begin a kickstart installation. The configuration file /tftpboot/linux-install/pxelinux.cfg/pxeos.xml contains specific definitions about which network install profiles are available to PXE boot clients.

That’s it for the Provisioning and Deployment section. As always, please let us know if you found the above mentioned useful and any comments/feedback you may have. Thank you for tuning into Port25.

In Case You Missed It...

admin — Thu, 27 Apr 2006 21:34:00 GMT

Original Post:

Tuesday, April 18, 2006 4:30 AM by Rick Strom

Ok Bill, I have a real suggestion here that is hopefully within the scope of what you are doing (and hopefully you're still reading the comments here). I'd also like to voice it to someone else at Microsoft since the MS rep I spoke to tonight blew me off.

Visual Studio 2005 should support CVS out of the box, or via an after-market but MS-developed add-in. The Microsoft rep knew as well as I do why Microsoft wants to push "Team System" over CVS -- namely, because it makes OSS development on SourceForge (and elsewhere) for the Windows platform a pain in the butt.

I love Visual Studio -- since I switched, I haven't looked back. But its hard to fully love a product that doesn't do something which really should be quite obvious. If Microsoft is worried about the potential harm that would come from facilitating development of SourceForge projects, or CVS projects in general, I think they are missing the bigger picture. A first class compiler like VS 2005 with a built in CVS client? You wouldn't just dominate the market, you'd own it. You would also benefit from a much larger number of (free) applications for the Windows OS, which would in turn reduce the chance of losing users to a Linux desktop.

"Trust me, Team System is better than CVS" and "maybe SourceForge will look into Team System" are not good answers (but those are the answers I got from the MS rep). Casual users can be convinced to do things a certain way, but developers generally tend to like to decide for themselves how they want to work. One of the things that has made Visual Studio so great is that it tries -- and succeeds, for the most part -- to be everything to everybody. With VS 2005 they seem to be going in another direction, and that makes it hard for me to seriously consider the upgrade from VS 2003.

Response:

Hi Rick,

My name is Eric Lee, and I’m the product manager for Team Foundation Server – a product in the Visual Studio Team System family.

First, let me apologize on behalf of the Microsoft rep that blew you off about this - Visual Studio is certainly a product who cares very deeply about the opinions of its customers.

You have a good point – simple, bullet-proof, cheap/free version control is certainly something that all developers need; whether they are doing OSS, running a small business, or part of large enterprise.

Before I try to address your question directly, let me spend a paragraph or two talking about how we think of version control and extending Visual Studio at Microsoft – I’d be happy to hear your opinions on this.

The introduction of Team System gives us two version control offerings from Microsoft – Visual Source Safe and Team Foundation Server (TFS). Visual Source Safe (VSS) is what we like to think of as where change management begins – it’s simple, relatively cheap, easy to setup and doesn’t require a server.

VSS will start to bog down a bit when it’s pushed beyond its scope – for example, it has no work item tracking, limited remote access and limited parallel development capabilities. This is where Team Foundation Server comes in – Team Foundation Server is a from-the-ground up implementation of version control, work item tracking, and release/project management integrated into a single collaboration server. TFS uses XML Web Services for communication and SQL Server 2005 as its data store. Both TFS and VSS integrate out of the box with Visual Studio 2005.

In terms of extending Visual Studio, we have always been very cognizant of making Visual Studio as extensible as possible – both for commercial and non-commercial partners. Lost in all of the announcements of Visual Studio 2005 is that our Visual Studio Industry Partner Program (VSIP) now has a free membership option. This membership gives you access to the SDK that enables extension of VS2005.

Part of the Visual Studio SDK is the MSSCCI interface (pronounced ‘misky’) that enables partners to implement version control providers; this interface is part of our SCC API. This interface has become something of a de facto standard for development environments. This interface gives you access to events like ‘user is trying to edit a file’ so that you can implement your ‘check-out’ operation. This interface also allows you to provide locked and unlocked glyphs – basically all the aspects of a version control system. We provide a skeleton version control provider as an example. Integrating CVS with Visual Studio would involve writing a provider that uses MSSCCI – there are some examples out there today.

Now to address your concern more directly; CVS – VS integration is a perfect example of the balancing act we have to do in Visual Studio. On one hand, an ‘out of the box’ solution might be very appealing to our customers; but on the other hand, doing this would take an opportunity away from our partners. In order for Visual Studio to be successful, we feel we have to build it as a platform, and help create a healthy ecosystem of partners. Doing this means providing viable opportunities for our partners to build value onto VS. Finding this balance isn’t an exact science, we use a number of ways to get feedback from our partners and we disclose our early plans to our VSIP Alliance and Premier partners. All of this is done to try to find a happy medium; we don’t do this perfectly all the time, but it is certainly something we constantly evaluate and invest a great deal of time in.

CVS integration in particular – because of the potential partner opportunity and the overlap it would introduce with VSS and TFS - is likely not something we would produce out of the box with Visual Studio.

However, the idea of a simple, bullet-proof, built-in version control system is something we are thinking hard about for future versions of Visual Studio. The idea of what is integrated in an IDE is changing and expanding all the time, maybe it is time to include version control as a natural part of an IDE? Would that be a streamlined version of TFS, a free copy of VSS, or something else? These are certainly all possibilities. I’d be happy to discuss your thoughts on this as well.

Thanks for taking the time to share your opinion with us.

Eric.