CLI -vs- GUI

Upon becoming a Database Engineer, I have encountered a number of things that are not thoroughly discussed in the classes that Microsoft provides for a price. These classes generally use the GUI to perform tasks such as backup, restore, shrinking, etc., instead of using the command-line. I assume that this is due to the time that it could take to get the commands typed vs the time it takes to go clickety clickety done.
Unfortunately, when connected to the SQL server with the GUI, one sometimes cannot perform certain tasks that require the database to be in a state with no connections. The GUI itself creates multiple connections, so this can be really bewildering for the noob DBA.
It is necessary to learn how to perform all tasks from the query analyzer first, and then with the knowledge of how the whole thing works, working from the GUI becomes almost laughable.

Revenue Generating Projects vs Operational Integrity Projects

This is a real sticking point for most of today’s businesses: should we devote our energies to projects that generate money, or projects that will keep us generating money in the future?
You may be amazed and frightened to learn that most CFO/CIO types will almost always pick the former to satisfy the perceptions of their audience; the CEO/Stockholders. Usually, IT/IS groups will only get buy-in for projects that don’t make money after the shit hits the fan.
In a lot of cases, this means that you are stepping in to a new role where your predecessors have been blamed for the shortcomings of the broken system that they were likely ardently trying to get fixed, but only receiving push-back. The IT folks generally wind up implementing stop-gaps and workarounds to the issues to satisfy the perceptions of their audience; the User/Customer.
Due diligence needs to take place and many eyes and ears need to be available to determine which projects should be pushed through and why. If revenue is of primary interest, then more funds need to go toward headcount to balance out the need for what should be the strong secondary interest, operational integrity.
It seems like common sense to me that once the car will not start any longer, one cannot drive to the store…

Moab... enjoy!

Active Directory Authentication on a Debian Linux System

Frequently, I am asked how well Linux operates within an Active Directory environment. Even with distributions such as Debian, the process is fairly straightforward and simple.

As a note of caution: the following assumes that you actually know a bit about what you are doing with the systems involved; you just want to know how to integrate your Debian/GNU Linux system into your Active Directory.

The changes you will need to make (especially to the /etc/pam.d/* configuration files) will make it so you cannot log on to your system ever again if you do something wrong, or if there is something erroneous in this document.

Always leave at least one shell open logged in as root. Do not log out until you verify you can log back on!

Here and there I will have things like ADDomain.com and ADDomainController. It is presumed that you know what your Active Directory short and long names are and what a Domain Controller is. If this is not the case you might reconsider attempting this at work...

So, on with the good stuff...

1. Install packages for MIT Kerberos, Samba, Winbind, and NTP.

a. apt-get install libkrb53 krb5-config samba winbind ntpdate ntp-server

b. Accept defaults as these will be changing later.

2. Stop services.

a. /etc/init.d/samba stop

b. /etc/init.d/winbind stop

c. /etc/init.d/ntp-server stop

3. Customize the following configuration files (probably using the default files as a start…):

a. /etc/krb5.conf:

[libdefaults]

default_realm = ADDomain.com

clockskew = 300

default_keytab_name = FILE:/etc/krb5.keytab

[realms]

ADDomain.com = {

kdc = DC.ADDomain.com

admin_server = DC.ADDomain.com

default_domain = ADDomain.com

}

[logging]

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmin.log

default = FILE:/var/log/krb5lib.log

[domain_realm]

.ADDomain.com = ADDomain.com

[appdefaults]

Pam = {

ticket_lifetime = 1d

renew_lifetime = 1d

forwardable = true

proxiable = false

retain_after_close = false

minimum_uid = 100

try_first_pass = true

}

b. /etc/nsswitch.conf

passwd: files winbind

shadow: compat

group: files winbind

# passwd: compat

group: compat

hosts: files dns winbind

networks: files dns

services: files

protocols: files

rpc: files

ethers: files

netmasks: files

netgroup: files

publickey: files

bootparams: files

automount: files nis

aliases: files

c. /etc/ntp.conf

# pool.ntp.org maps to more than 100 low-stratum NTP servers.

#Your server will pick a different set every time it starts up

#***Please consider joining the pool! ***

serverIP.OF.Your.Server

Leave the rest of the file as defaults.

d. /etc/defaults/ntpdate

# servers to check. (Separate multiple servers with spaces.)

NTPSERVERS="IP.OF.Time.Server(DC usually)"

#

# additional options for ntpdate

#NTPOPTIONS="-v"

NTPOPTIONS="-u"

e. /etc/pam.d/common-auth

auth sufficient pam_winbind.so

auth required pam_unix.so use_first_pass

f. /etc/pam.d/login

auth requisite pam_securetty.so

auth requisite pam_nologin.so

auth required pam_env.so

@include common-auth

@include common-account

@include common-session

session required pam_limits.so

session optional pam_lastlog.so

session optional pam_motd.so

session optional pam_mail.so standard noenv

@include common-password

g. /etc/pam.d/sshd

auth include common-auth

auth sufficient pam_succeed_if.so login = root

auth required pam_winbind.so use_first_pass require_membership_of=ADAdminGroup

auth required pam_nologin.so

account required pam_winbind.so use_first_pass require_membership_of=ADAdminGroup

account include common-account

password include common-password

password sufficient pam_winbind.so use_first_pass use_authtok require_membership_of=ADAdminGroup

session include common-session

session optional pam_mkhomedir.so

h. /etc/samba/smb.conf

This is really up to you. Pertinent parts are:

1. winbind separator = %

2. workgroup = SHORT_AD_DOMAIN

3. netbios name = HOSTNAME

4. password server = ADDomainController

5. winbind use default domain = yes

6. winbind cache time = 10

7. realm = ADDomain.com (long name)

8. security = ADS

9. encrypt passwords = yes

10. idmap backend = idmap_rid:SHORT_AD_DOMAIN=10000-200000

11. idmap uid = 10000-200000

12. idmap gid = 10000-200000

13. winbind enum users = yes

14. winbind enum groups = yes

15. template shell = /bin/bash

16. template homedir = /home/%D/%U

17. domain master = no

18. local master = no

19. preferred master = no

20. wins server = IP.OF.WINS.Server

21. name resolve order = wins bcast hosts

22. use kerberos keytab = true

23. use sendfile = no

4. Verify that ntp is talking to Time Server

a. ntpq –p

b. output should be like the following:

remote refid st t when poll reach delay offset jitter

==========================================

*ts.somedomain.com 192.168.1.2 3 u 243 512 377 0.492 -32.931 7.568

LOCAL(0) LOCAL(0) 13 l 29 64 377 0.000 0.000 0.004

c. If the response is in the form of an error, you will need to set up ntp-server.

5. Join the Domain.

a. net ads join -U username (user must have Domain Admin privileges.)

b. type in your password.

6. Start services.

a. /etc/init.d/ntp-server start

b. /etc/init.d/samba start

c. /etc/init.d/winbind start

7. Check Name Resolution.

a. getent passwd (should give you /etc/passwd info as well as AD users)

b. getent group (as above, but groups…)

8. At this point you should be able to log on in a SSH session with your AD credentials.

SLES/SLED 10 -vs- OpenSuSE 10

A far as I can see, SLES is certainly a step in another direction from OpenSuSE 10.0. With OpenSuSE 10.0, one could (if one wanted) select a text-only installation with no X-Server whatsoever, where the SLES installer requires some kind of X to be installed. Text-only is ideal for the data center and servers in general. You usually don't want to waste CPU time on a GUI unless your support staff can't handle being locked into a console. The irony here is that there is not much of use to be done outside of the command prompt in the UNIX world. Sure, there are GUI front-end applications that are really just running the CLI utilities for you, but that isn't really the same. It saddens me that the *UX world is slipping down the slope toward the same "building for the lowest common denominator" philosophy that Microsoft and Apple have upheld for so long.

Of course, you really only find this behavior in the realm of the "Linux for the masses" distro. i.e. Redhat, SuSE, Fedora, yada...
Debian and Slackware are still, in my opinion, the premier Linux distributions and are the only real choices for non-hobbyist systems.