Getting wireless network working on CentOS 5 and Thinkpad T42
by Mats Hellman on 15.Dec, 2008 under Linux
I pulled an old IBM Thinkpad T42 to use as a “light” and “mobile” laptop on the daily train ride to Helsinki. It’s not new but more than usable with 768Mb RAM and CentOS 5 installed. This gives me a full development environment to work with on the train. What I noticed was the problem to get the wireless network up on this thing.
I tried editing /etc/wpa_supplicant/wpa_supplicant.conf, I ran iwconfig. I scanned etc. And it just didn’t want to work.
The hardware seemed to be working, but not the network settings. Why?
Google to the rescue
As always when you are troubleshooting the place to start is google.com.After reading a lot of pages, some better some worse I found NetworkManager. How could I have missed this? Later I even found a document at centos.org describing how to use this.
Using NetworkManager
Finding I should use NetworkManager I started up the service and stopped the network service. I got a list of the Wireless networks and 10 seconds later I was surfing with the wireless network.
To set NetworkManager to start automatically you should do the following
[root@localhost ~]$ service NetworkManager start
[root@localhost ~]$ chkconfig –level 2345 network off
[root@localhost ~]$ service network stop
You should now have a nice network icon in your Gnome system tray and clicking it should show the wireless networks available.
Installs
To be clear this is what I installed.
The , to get a lot of packages. And after setting up rpmforge I just pulled firmware for the network card.
This page is mostly a note for myself but if it helps someone else out then all the better.
Installing Microsoft Corefonts on CentOS 5
by Mats Hellman on 12.Dec, 2008 under Linux
This is a thing I always have to google when I need to install Microsoft’s fonts in my CentOS installs so I thought I’d post a short dirty note here to remind me how to do it.
First of all we need some tools to build ourselves the RPM for msttcorefonts, so fire up your terminal and
When finished run the following as root
[root@localhost build]$ rpmbuild -ba msttcorefonts-2.0-1.spec
[root@localhost build]$ rpm -ivh /usr/src/redhat/RPMS/noarch/msttcorefonts-2.0-1.noarch.rpm
[root@localhost build]$ /sbin/service xfs reload
That’s it. You should now have Microsoft’s standard fonts installed and ready to go.
From installation to Active Directory client with CentOS 4.2 – Part two
by Mats Hellman on 22.Aug, 2006 under Linux
This is the second part of an article I started a _long_ time ago explaining how to connect a Linux desktop to Microsofts Active Directory, this time with the CentOS distribution. The first part can be found here. Hopefully you now have CentOS setup and are getting eager to get the domain logins working. We will get to that in a minute. First let’s discuss the process overall and what you already need to know or have setup. This guide has no guarantee on working, you should also backup any important data before proceeding. If you run in to trouble post in our forums and we’ll do our best to help you. A good practice is to backup the configuration file you are about to edit, so if you run into problems you can reset it to the original file. Remember, playing with authentication can get you locked out of your system!
You need:
- Working Windows domain with Active Directory.
- CentOS 4 installed on a desktop or virtual machine (VMWare, Microsoft Virtual PC or server).
Also you need to have the following information at hand:
- Your Windows domain name.
- The name of the Active directory domain controller.
- User account and password for an administrative account in the domain.
That’s it. Now let’s get on with configuring the system.
In this article:
- Installing OpenLDAP.
- Configuring Samba .
- Starting the winbind daemon.
- Adding the workstation to the domain.
- Configuring /etc/nsswitch.conf
- Testing winbind
- Testing Windows to Linux account conversion.
- Editing /etc/sysconfig/samba.
- Editing PAM settings.
- Starting the daemons.
- Further reading.
- Troubleshooting.
Well start by installing OpenLDAP and the clients also we need nss_ldap. YUM handles the installations for us nicely so we don’t have to worry about dependencies. Just fire up a terminal because that’s where well spend a lot of time in this part of the article.
| [root@wrkst1~]$yum install openldap-clients openldap |
Configuring kerberos.
When OpenLDAP is installed we can move on to configuring the different authentication handlers. Let’s start by configuring the network authentication protocol Kerberos.
We need to tell Kerberos the windows realm and a few other things. Kerberos configuration file resides in /etc/krb5.conf so fire up your favourite editor, I’m using both Emacs and Vi depending on the situation so no editor wars here, and open the file for editing.
You should see something like this:
| [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] [realms] [domain_realm] [kdc] [appdefaults] |
Now let’s edit the file. You did back it up like I told you didn’t you 
. Remember this file IS case sensitive, so default is not the same as DEFAULT. Remember to change the values if you copy/paste.
| #/etc/krb5.conf |
| [libdefaults] ticket_lifetime = 600 default_realm = NIXADMINS.NET default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc [realms] [domain_realm] [kdc] [logging] |
Save the file and exit. Next let’s make the system a little more error tolerant, in case the DNS service goes down the workstation won’t be able to authenticate the domain users so we add the Active Directory PDC server to the /etc/hosts file. Add the following line to /etc/hosts:
| # /etc/hosts |
| 1.2.3.4 ad-server.nixadmins.net ad-server |
Next we need to test to see if our Kerberos settings are working. Just type the following in your terminal, all it does is return you to the prompt if everything is working.
| [root@wrkst1~]$ kinit aduser@NIXADMINS.NET |
That’s it for Kerberos, it wasn’t that hard now was it.
Samba is used to set some Windows domain information and the machine name. Also we define where and how the user directories are and which the default user shell is. Here is my smb.conf, read it trough and change at least the values workgroup (the wins domain name), realm (the domain DNS name in capitals) and password server (your PDC).
| # /etc/samba/smb.conf |
| [global] workgroup = NIXADMINS netbios name = wrkst1 server string = Linux workstation 1 security = ADS log file = /var/log/samba/samba.%m max log size = 50 local master = no preferred master = no idmap uid = 10000-20000 idmap gid = 10000-20000 winbind gid = 10000-20000 winbind enum users = yes winbind enum groups = yes winbind use default domain = yes template homedir = /home/%U template shell = /bin/bash encrypt passwords = yes dns proxy = no realm = NIXADMINS.NET password server = ad-server.nixadmins.net wins proxy = no |
Before we move on let’s check our /etc/samba/smb.conf file to see if there are any errors in it.
| [root@wrkst1~]$ testparm Load smb config files from /etc/samba/smb.conf Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions # Global parameters |
Let’s start the winbind daemon that is responsible for the queries against Active Directory and find out if our setup is working. Before you do this be sure to check that neither smbd or nmbd are running.
| [root@wrkst1 ~]# service smb status smbd is stopped nmbd is stopped [root@wrkst1 ~]# service winbind start Starting Winbind services: [ OK ] [root@wrkst1 ~]# |
Adding the workstation to the domain.
Now that we have a working winbind we can add the workstation to the Windows domain. Run the following command. Use the Windows Administrator account or another account that has the rights to add a computer to the domain.
| [root@wrkst1 ~]# net ads join -U Administrator Administrator’s password: Using short domain name — NIXADMINS Joined ‘WRKST1′ to realm ‘NIXADMINS.NET’ [root@wrkst1 ~]# |
That’s it. The workstation should now be located in the computers holder in the Windows domain.
Configuring /etc/nsswitch.conf.
Edit the file top part of the file /etc/nsswitch.conf.
| Before: # some text before this part passwd: files shadow: files group: files # and some after also, let them be |
| After: # some text before this part passwd: compat winbind shadow: compat group: compat winbind # and some after also, let them be |
Now let’s test winbind to see if we really are communicating with Active Directory. To do this we use the command wbinfo with the switches -u and -g, -u to query users and -g to query groups.
First let’s query for users in the directory, you output should look something like below.
| [root@wrkst1 ~]# wbinfo -u NIXADMINSAdministrator NIXADMINS******* NIXADMINS******* …………. [root@wrkst1 ~]# |
And next let’s query for groups.
| [root@wrkst1 ~]# wbinfo -g NIXADMINSHelpServicesGroup NIXADMINSTelnetClients NIXADMINSDomain Computers NIXADMINSDomain Controllers …………. [root@wrkst1 ~]# |
Testing Windows to Linux account conversion.
We need to be sure this is working properly or our users won’t be able to log in to the workstation. The command getent shows us all accounts or groups.
First let’s check the users, run the following
| [root@wrkst1 ~]# getent passwd |
And then the groups
| [root@wrkst1 ~]# getent group |
Add -D to the winbindoptions part of /etc/sysconfig/samba, the file should look like this
| # Options to smbd SMBDOPTIONS="-D" # Options to nmbd NMBDOPTIONS="-D" # Options for winbindd WINBINDOPTIONS="-D" |
IMPORTANT! Make a backup of the whole /etc/pam.d folder before you continue.
Made the backup? Ok, let’s continue.
Let’s edit the file that handles the logins. Edit your /etc/pam.d/login to look like this
| #%PAM-1.0 | ||
| auth | required | pam_securetty.so |
| auth | sufficient | pam_winbind.so |
| auth | sufficient | pam_unix.so use_first_pass |
| auth | required | pam_stack.so service=system-auth |
| auth | required | pam_nologin.so |
| account | sufficient | pam_winbind.so |
| account | required | pam_stack.so service=system-auth |
| password | required | pam_stack.so service=system-auth |
| # pam_selinux.so close should be the first session rule | ||
| session | required | pam_mkhomedir.so skel=/etc/skel umask=0022 |
| session | required | pam_selinux.so close |
| session | required | pam_stack.so service=system-auth |
| session | required | pam_loginuid.so |
| session | optional | pam_console.so |
| # pam_selinux.so open should be the last session rule | ||
| session | required | pam_selinux.so open |
Note: we adde
Software Installation by Group Policy
by Mats Hellman on 13.Dec, 2005 under Linux
For a large software deployment, most IT departments do not have the staff or time
to install the software on each machine individually. In this article, I will
show you how you can configure a Group Policy to install the software on each
machine automatically from a central point.
Creating a Group Policy Object (GPO)
Creating a Software Installation Package
Checking your Software Installation Policy
What is Group Policy?
Group Policy is a huge topic.
I don’t consider myself an expert by any means with Group Policy and I have
been working with it for a few years already. For the purpose of this article,
you need to understand that Group Policy is a feature available in Windows XP,
Server 2000 and 2003 that allows you apply policies to computers and users in
your network. A group policy may be applied Site-wide, Domain-wide, or
Organization Unit (OU)-wide. In this article, we will be applying a Group
Policy Object (GPO) to an OU that I have already created.
Creating a Group Policy Object (GPO)
Creating a GPO is simple. All
you need to do is select your Organization Unit (in our case), right click on
it and choose Properties. From the Properties window, click on the Group Policy
tab and click the ‘New’ button, as shown in Figure 1.
Figure 1: Creating a New GPO
Editing Your GPO
Editing your GPO is about as
easy as creating it. Note that you must be a member of the Administrators or
Domain Administrators group in order to edit a GPO. To edit your newly created
GPO, simply click the ‘Edit’ button.
Figure 2: Editing your GPO
Creating a Software Installation Package
Now that we have created our
GPO, we must define what goes in it. In this article, we will focus on creating
a Software Installation Package to make software deployment automated on
multiple clients.
Software Packages can be
Assigned or Published to either Computers or Users. You may use any combination
of the four, depending on your scenario. Let me give you a few examples:
- Assigned
to Computer: you are deploying
software to multiple clients and require the software to be installed on
all of the computers in the OU. - Assigned
to Users: the Users in your OU
require a special application to be installed on every computer that they
log on to. - Published
to Computer: there is an upgrade
(ie: Windows Media Player) that is optional to all computers in your OU
and can be installed if the user on that computer wishes. - Publish
to User: if the users in your OU
use multiple computers and you want them to have the option to have their
software with them, they can install any published package on any computer
they are on.
It is important to note that
only software that includes an MSI install package can be deployed via Group
Policy. If your software does not have an MSI installer, there are third-party
programs that will repackage your application into an MSI – I have yet to find
one I actually like and would recommend, though.
To create a new Software
Installation Package, you can navigate to the ‘Software Settings’ folder in
either the Computer Configuration or User Configuration, depending on your
deployment requirements. In our scenario, we will be publishing an application
to a user so under the User Configuration, we will click on ‘Software
Settings’. Next we right-click on ‘Software Installation’ and then ‘New’ and
‘Package’ on the menu
Comments Off
