HOWTO: install puppet-dashboard on Debian Squeeze

This should apply to Ubuntu Server as well (10.10, 11.04) but it’s tested to work 100% on Debian Squeeze 6.0.
Puppet Dashboard is a neat piece of software really useful if you ara managing a good number of hosts without Puppet.

First of all, install the required deps:

# aptitude install ruby rake dbconfig-common libdbd-mysql-ruby mysql-client rubygems libhttpclient-ruby1.8

you’ll probably have lots of them already installed if you are running Puppet master on the same host (which by the way is not mandatory).
Then, download and install the deb package:

# wget http://downloads.puppetlabs.com/dashboard/puppet-dashboard_1.2.0-1_all.deb
# dpkg -i puppet-dashboard_1.2.0-1_all.deb

Enable the daemon editing the default file /etc/default/puppet-dashboard and then customize your database definition by editing /etc/puppet-dashboard/database.yml which should looks something like this:

production:
database: puppet_dashboard
host: your.database.host
username: puppet_dashboard
password: secret_password
encoding: utf8
adapter: mysql

if you plan to use MySQL as a backend. Remember to create the database and grant the appropriate privileges to the user

GRANT ALL PRIVILEGES ON puppet_dashboard.* TO 'puppet_dashboard'@'%' IDENTIFIED BY 'secret_password';

Now we have to populate the database, Rails way

# cd /usr/share/puppet-dashboard/
# rake RAILS_ENV=production db:migrate

Now you can start /etc/init.d/puppet-dashboard and /etc/init.d/puppet-dashboard-workers and you should be already able to access http://your-host.yourdomain.tld:3000 and see the Puppet Dashboard.
You just have to do two thing more before you can see any actual data in it: enable report sending in the Puppet clients and tell Puppet Master to pull those reports to the Dashboard via HTTP.

So, edit /etc/puppet.pupept.conf on the clients (I suggest you to do it via puppet if you do not already have this setting in it) and add

[agent]
# ... whatever you already have
report=true

and on the Master side

[master]
# ... whatever you already have
reports = store, http
reporturl = http://your-host.yourdomain.tld:3000/reports/upload

That’s it!

Advertisements

HOWTO: Poor man VPN in Debian/Ubuntu with OpenSSH

If you are managing a remote Linux network and you are tired of NATting or two ssh hops to enter a remote server, but OpenVPN poses too much overhead, you can use ssh tunneling to easily create a workstation-to-site VPN.
I’ve tested this with Ubuntu 9.10 Karmic Koala as the workstation and Debian 5.0 Lenny as the server, but it should work identically with older Ubuntu and Debian (both server or workstation).

I’ve been inspired by these two tutorials, although both didn’t work 100% for me, but joining pieces did the trick, so here I am :)

Software prerequisites:

  • Standard Debian or Ubuntu
  • openssh-server on the remote side of the VPN
  • openssh-client on the local side of the VPN (your PC)

Network configuration (as an example)

  • Workstation LAN: 192.168.0.0/24
  • Server LAN: 192.168.10.0/24 on eth1
  • VPN: 10.0.0.0/24
  • Remote server public address: 1.2.3.4 on eth0

First of all, on the workstation generate a dedicated key (it should be a dedicated one cause the server will identify you’re going to bring up a tunnel based on the key you’re using to connect) with

# ssh-keygen -f /root/.ssh/VPNkey -b 2048

Now edit /etc/network/interfaces and create a new stanza like this one (remember to change IP addresses – in bold – according to your personal network configuration)

iface tun0 inet static
# from pre-up to true on the same line
pre-up ssh -i /root/.ssh/VPN -S /var/run/ssh-vpn-tunnel-control -M -f -w 0:0 1.2.3.4 true
pre-up sleep 5
address 10.1.0.2
pointopoint 10.1.0.1
netmask 255.255.255.0
up route add -net 192.168.10.0 netmask 255.255.255.0 gw 10.1.0.1 tun0
post-down ssh -i /root/.ssh/VPN -S /var/run/ssh-vpn-tunnel-control -O exit 1.2.3.4

Just a copuple of notes: address is your VPN local endpoint address (say, your workstation) while pointopoint is the remote VPNaddress (your server), which are the two tunnel’s endpoints.

Now let’s go to the server.

Edit /etc/ssh/sshd_server, add the line
PermitTunnel point-to-point

and restart your sshd instance.
Now edit (or create) /root/.ssh/authorized_keys (remember, we are on the server now, not your workstation) and add a line like

tunnel="0",command="/sbin/ifdown tun0; /sbin/ifup tun0" ssh-rsa HERE IT GOES YOUR VPNkey.pub FROM YOUR WORKSTATION

now edit /etc/network/interfaces and add this stanza:

iface tun0 inet static
address 10.1.0.1
netmask 255.255.255.0
pointopoint 10.1.0.2
post-up /sbin/sysctl -w net.ipv4.ip_forward=1
post-up /sbin/iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -o eth1 -j MASQUERADE
post-down /sbin/iptables -t nat -D POSTROUTING -s 10.1.0.0/24 -o eth1 -j MASQUERADE
post-down /sbin/sysctl -w net.ipv4.ip_forward=0

the post-up and post-down commands enable the network sharing between the VPN server endpoint and the remote LAN (it’s called masquerading), so you can access the remote LAN from your workstation and not only the remote server. Obviously you need to instruct your workstation with a dedicated static route to reach the remote LAN network, and this is the route add -net in your workstation config.

Now, bring up the tunnel on the workstation with
# ifup tun0
and you should be able to reach a remote server on your remote LAN, with traffic secured by OpenSSH encryption.

Ubuntu 9.04 and UXA acceleration in X.Org

With the recent release of Ubuntu 9.04 and the brand new X.org stack, finally I have got quick and usable windows effects in my KDE 4.2 install (using Kwin, not Compiz).
My workstation is a Dell Optiplex 745 with an Intel grapphic chipset

$ lspci|grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)

with the default install I had serious problems with X, and with serious I mean textures corruptions, artifacts with KDE/Qt4 applications and all sort of graphic glitches.. really a PITA. Then the great idea: Ubuntu 9.04 now ships with a DRI2 enabled kernel, GEM for graphic memory management and this new Intel-sponsored acceleration framework called UXA, which is supposed to improve XAA and EXA. So, if everything is already screwed, why not give it a try?

So I fired up my vim editor and changed my /etc/X11/xorg.conf to look exactly like this, no more no less:

Section "Monitor"
 Identifier      "Configured Monitor"
EndSection

Section "Screen"
        Identifier      "Default Screen"
        Monitor         "Configured Monitor"
        Device          "Configured Video Device"
EndSection
Section "Device"
        Identifier      "Configured Video Device"
        Option          "AccelMethod" "UXA"
EndSection
Section "ServerFlags"
        Option  "DontZap"       "False"
EndSection

restarted X and the magic was done. I activated the composited effects in KWin and everything worked like a charm, really flying as it never did and as it is supposed to do (Vista on the same hardware works the same).
So, if you have a similar hardware, I encourage you to try the same. If anything goes wrong, removing this line

Option "AccelMethod" "UXA"

will fall back the configuration to its default state.

HTH

mii-tool is deprecated, use ethtool

Title says it all. If you want to check (or set) your ethernet NIC configuration or status in Linux, people used to use mii-tools. But there’s a lot more powerful and modern tool that obsoletes it: ethtool
You can install it with your favourite package manager, if it’s not already present in your system.
In Debian/Ubuntu, you can issue
# aptitude install ethtool

Here it is an example:


# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes

HOWTO: Managing Active Directory users under Linux with adtool

Usually people manages Linux boxes using Windows clients but sometimes, someone (like me, for example) needs to manage a Windows server from a Linux host (it could be a normal client or another server which wants to talk to Windows).

IMO, Active Directory is one of the best product from Microsoft, since it’s based on a well known standard like X.500 (aka LDAP) and it has a good interoperabilty (although it could be better, see all the problems Samba people had in the past).  So, even if there are tools like PHPLdapAdmin which are pretty good, if you need to automate users and groups management, there’s nothing better than a command line tool. Enter adtool.

adtool is very simple to use, but it’s not so simple to have it up&running, because this involves, amongst other things, to activate Secure LDAP in your Active Directory installation. To do this, you can follow this guide which will lead you through all the steps you have to do to enable LDAPS in Windows Server 2003. It may look scary but it works indeed, I used it myself.

Then, install adtool. In Debian/Ubuntu

# aptitude install adtool

Probably adtool is already present in your distribution’s repositories, so use your package manager. In the case it’s not present, simply download the adtool tarball from its homepage and do the usual

$ tar xzvf adtool-1.3.tar.gz
$ cd adtool-1.3
$ ./configure
$ make
# make install

It should be quite straightforward.
Now we have everything installed, so we can configure adtool.
Create /etc/adtool.cfg or, even better $HOME/.adtool.cfg because it will contain sensitive information, so lock it up to the user you’re willing to employ to modify Active Directory.
Put this in the config file (adapt to your needs)

uri ldaps://domain-controller.domain.tld
binddn cn=Administrator,cn=Users,dc=domain,dc=tld
bindpw $ADMIN_PASSWORD
searchbase dc=domain,dc=tld

As you can see we are using LDAPS here, because otherwise some adtool features like changing users’ passwords wouldn’t be available.
You don’t necessarily have to use the Administrator account, you can use whatever account you want, it just needs to have the right permissions (create user, change passwords etc).

So you can start poking your AD from the Linux command line, like this:

# create a new user with a dn like cn=$NAME,ou=$DEP,dc=domain,dc=tld
$ adtool usercreate "$NAME" "ou=$DEP,dc=domain,dc=tld"

# set user logon password
$ adtool setpass "$NAME" $my_secret_password

# to unlock the account (locked by default)
$ adtool userunlock "$NAME"

# to disable all the "account options" in the user's account tabe. Amongst them the "Password never expires" which is again enabled by default
$ adtool attributereplace "$NAME" userAccountControl 512

# to set user's mail address
$ adtool attributeadd "$NAME" mail user@domain.tld

# add the user to a group of users
$ adtool groupadduser $my_group "$NAME"

This could be very useful for user scripting and system integration if you’re in a mixed environment, just like we are.

HOWTO: Active Directory authentication in Ubuntu 8.04 and 8.10

This is a second version of this other guide that applied to previous Ubuntu versions.
Since Ubuntu 8.04 (Hardy Heron), and now Ubuntu 8.10 (Intrepid Ibex) it come the Likewise Open package that makes basic Active Directory authentication in Ubuntu a breeze.

Just follow these steps:

  1. sudo apt-get update
  2. sudo apt-get install likewise-open
  3. sudo domainjoin-cli join fqdn.of.your.domain Administrator
  4. sudo update-rc.d likewise-open defaults
  5. sudo /etc/init.d/likewise-open start

and you can now log into your machine using your DOMAIN\user credentials. Remember that the DOMAIN\ part is mandatory and that it represents the short name of your Active Directory domain. You can join the domain using any user with sufficient privileges (there’s no need to use Administrator), and you can even directly join the PC in a particular OU passing the –ou argument to domainjoin-cli. The fourth point maybe won’t be necessary when Ubuntu 8.04 LTS wil be released because it seems to be a bug in the package (it won’t start likewise on reboot, so if you don’t issue this command it would seem that nothing is working after a reboot).

I’ve just started to use this method on a test machine so I’ll leave more opinions on this product in the future.

EDIT: First impressions

After some days of not so extensive usage, I’ve seen a couple of things that it’s worth notice:

  • the likewise-open process seems to “die” from time to time, blocking all your login accesses with a “ERROR” message. Restarting it through init script solves the issue… but it’s something that definitely should not happen
  • It informs you on login if your password is going to expire in X days (as set in your GPO). Very nice indeed.

Notes to the readers: if you’re experiencing installation problem, the best way is to report them to the likewise-open-discuss mailing list. There you can contact directly likewise developers (of Samba fame) and solve your problems or doubts.

EDIT2: it seems that with the final Ubuntu 8.04 update, likewise-open package is now 100% stable, I didn’t have a single failure since last update (one week up, while before it died at least once per day)

EDIT3: as mentioned in the comment, with likewise-open 4.x you can add

winbind use default domain = yes

in /etc/samba/lwiauthd.conf so you d’nt have to specify the DOMAIN\ part every time you log in your box.

Obtain the Dell service tag in FreeBSD/Debian/Gentoo

Well, the title could be a little misleading cause this actually works in Linux and with other manufacturer as well, but since we were searching info for this particular topic, and didn’t manage to find anything useful on Google…

Anyway, it’s very very simple. All you have to do is install dmidecode (from Alan Cox) with:

FreeBSD

portinstall dmidecode

or whatever manner you use to install FreeBSD’s ports :)

Debian/Ubuntu

apt-get install dmidecode

Gentoo

emerge dmidecode

NOTE: this work as well with HP servers’ serial numbers and, I suppose, with IBM, Sun etc too.

Once installed, all you have to do is execute

# dmidecode -s chassis-serial-number

et voilà, you will get your service tag printed on screen. Moreover if your server is in the datacenter and you cannot remember the exact model

# dmidecode -s system-product-name
PowerEdge 1750

for example.

Just a note: dmidecode is the program used by OCS Inventory client to collect all these data.