SUSE Studio allows you to build/create your own Linux distribution based on SUSE linux.

“Build an appliance — or your own custom Linux distro — with a few mouse clicks. Customize it to your heart’s content, and share it with the world!”

You can currently choose from one of many options available to create a OpenSUSE, SLES 10, SLED 10, SLES 11, or SLED 11 machine. You can create a custom boot menu with the option to upload your own image for bootsplash. Complete control over packages, ability to overlay files (this means you can inject scripts or your own program you are distributing) right into the machine.

Once you have completed creating your custom machine you can build it into a Live CD/DVD or a disk image (this can be DD’d onto a USB Stick or another for booting) or a VMWare Disk Image or a XEN Disk Image.

From here your SUSE Studio machine is just a quick download away, the machine I test built was just a 220MB download and on a 20mbit internet connection I was able to download my image at roughly 550kb/sec and took around 15 minutes.

This is a very well polished service and is currently still in beta. I can’t wait to see what these guys come up with next.

You will need your linode account number to use the graphs, you can find this number by looking at the graphs provided to you in your Linode account management interface. The title of the graph will be “http://www.linode.com/ – yourhostname (linode12345) – CPU – …….”. You will need the text from inside the ( ) for your username ie linode12345.

To install just copy the linode.pl file into the scripts directory of your Cacti installation. This script was taken from http://www.linode.com/forums/viewtopic.php?t=776 and modified for use with cacti.

Then just import the cacti host template file into Cacti. You should then be able to add the graphs to your relevant host.

Requirements:

• Cacti 0.8.7d
• Perl XML::LibXML
• Perl LWP::UserAgent
• Perl IO::File

Download

• Monitoring Linode Stats with Cacti

Ultimately if you are looking at having your own update repository then you will already have your own installation repository (if you don’t you can always go through the steps in Part 1 of my Autoyast how-to).

First of all create a directory inside your local repository called “updates” and then create a sub-directory for each of the versions you need (for me I only have opensuse11.1).

For you to update your individual servers after creating the repo you will need to have the “yast2-online-update-frontend” package installed.

Use the following command to initially create and update your repo.

rsync -a -v -v --delete-after --progress --stats \
mirror.internode.on.net::opensuse/update/11.1/ \
/var/lib/autoinstall/repository/updates/opensuse11.1-current/

This command will copy about 8gb’s of data, but as it is using rsync you can cancel it and restart it as often as you need. Be sure to select a mirror near you from the following list OpenSUSE Mirror List.

Next log on to one of your clients and perform the following:

1. Go into YaST

2. Software -> Software Management

3. Click Add

4. Select HTTP

5. Enter the relevant details

6. You should end with with a screen somewhat like the following

7. Goto Software -> Online Update

8. Select the required updates

And that’s it.

I have read a lot of blog posts and articles today and will list the ones I found most helpful below.

There is a lot of information out there that is now mostly out of date. PostgreSQL 8.3 changed the game when it came  performance tuning and a lot of the hard and fast rules that had been true for many years are now no longer true. So my one piece of advise when it comes to looking at the information out there, make sure it is relevant to the version of Postgres you are using.

The other thing to keep in mind are there are certain performance parameters that can improve performance, yet reduce reliability or time to restore objectives for your database and also the inverse of this decreased performance and increased reliability. You need to decide what your individual requirements are, it is mostly a counter balance between Performance and Reliability (reliability being anything from producing instability in the disk system by changing caching methods, through to the amount of data lost at power failure, or if using WAL log archiving how long between log writes and how often to write checkpoints). As always when changing any value that is suggested do your own research. For me I looked at the official Postgres documentation as well as just googling the setting name (ie shared_buffers) and reading information from the mail list archives and other tutorials.

Resources I used:

• http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
• http://blog.gtuhl.com/2009/03/08/postgresql-setup-basics/
• http://blog.gtuhl.com/2009/05/13/dell-md1120-perc6e-performance/
• http://www.postgresql.org/docs/8.3/static/

In this three part series we will explore creating a repository for use with multiple systems, creating and customizing the AutoInstall file, and finally running through an install procedure.

Part 3 – Putting it all together and installing a server

In this part we will look at running through a machine install making use of our newly created repository and AutoInstall file.

Check out Part 1 – Creating a repository for use with multiple systems
Part 2 – Creating and Customizing the AutoInstall file

What you will need:

• OpenSUSE Installation Media
• Server/Desktop/VM that has access to DHCP and the HTTP server holding the Repository

OpenSUSE Installation Media

You will need to boot the new machine with some form of installation media. This can be either the full installation DVD or my preference is the small network install CD (I prefer this as not all my servers have DVD drives, plus it is an 88mb ISO to upload to my VM Servers rather then a 5gb ISO). To get a copy of the Network Install disk goto http://software.opensuse.org/ and select Network for the installation medium.

Installation

For the screenshots in this Demo I am using a VM hosted on VMWare ESXi 4.0.

The machine should boot into the following screen.

To start with press F4 to bring up the source menu.

Select HTTP. You will then need to enter the details of your repository server (remember the directory in this context is the directory relative to the webroot)

The next part you need to fill in some extra details for the boot options.

autoyast=http://192.168.0.65/autoyast/autoinstall/demo.xml

This will be the AutoInstall file you have created.

Next select Installation and press enter. For the rest just sit back and wait.

If you didn’t select an automated installation you will be stopped before the following screen presented with all the information regarding the installation (change what you need to then hit Install).

This is after the first reboot, when presented with the install screen again just select “Boot from Hard Disk” or let it time out. You could also remove the CD/DVD just before the machine reboots.

And that is it. The machine install is complete. That concludes the series on AutoYast/AutoInstall. Sometime in the next few weeks I will put together a short howto on creating your own local Update repository.

In this three part series we will explore creating a repository for use with multiple systems, creating and customizing the AutoInstall file, and finally running through an install procedure.

Part 2 – Creating and Customizing the AutoInstall file

In this part we will look at creating an AutoInstall file for use with AutoYast.

Check out Part 1 – Creating a repository for use with multiple systems

For this part you will need a machine with OpenSUSE installed, the latest version would be best (although I think it should work with older versions, however I haven’t tested this theory).

Required Packages:

• autoyast2
• autoyast2-installation

In the next section we look at many different options. There are lots of things to explore, but I will leave this up to you. We will go through the basics:

• Disk Partitioning
• Network Setup
• Package Selection
• Users and Groups
• System Services (Runlevels)
• Basic Post Install Scripting

Firstly access YaST from either a X Windows session or from the Command Line (The screen shots are all from the command line version but the same rules should apply).

Goto the “Miscellanous – Autoinstallation” screen

Disk Partitioning

In this section I found it best to use “Auto” for the device. This way the same file works between my test server in VM, through to my HP Servers with RAID configurations.

For the most part you will just need to enter the details you want/need. But there are two things that needs to be pointed out with regard to partition sizes. What you can do is build a partition with size Auto (this is best used on your swap partition) and also with size Max which will fill the rest of the drive’s free space. So the layout I commonly use is:

• /boot with 128mb – EXT2
• SWAP with Auto
• / with 15GB – EXT3
• /var or /home with Max, EXT3 (Depending on the role of the server, typically /home for development/webservers and /var for database/mail servers)

Unfortunately, if you need to use software RAID Autoyast/Autoinstall will not work for you.

Network Setup

In the Network Settings screen click on Add.

Leave the defaults on the Hardware Dialog Screen (unless you want to change from Eth0 to Eth1,2,3….N, change the number in the Configuration Name Section).

Fill in the Network Card Setup screen with the options you require (ie, DHCP, Static Address, Additional Interface aliases).

Now back in the Network Settings screen go to Hostname/DNS and fill in the appropriate details there (Please note, this is one of the only things that needs to be changed for each server build, or alternatively you could build your servers with a generic name and change them after build).

Next fill in the required details in Routing and your done.

Package Selection

This section is relatively easy, all you need to do is fill in the details as you would for any installation. (The catch is you will first of all need to use the filter to display “Patterns” then at a bare minimum select “Base System”).

Users and Groups

Go to “Security and Users – User and Group Management” and at a bare minimum edit the Root user and set a password (if you don’t do this then you will not be able to login to the machine after it has been built).

At this point you can make any customisations you require for Users and Groups, as a best practice measure you should also create a non-root user and set a password for that account too.

System Services

You will also need to change the default system runlevel if you want a console only server, to do this goto “System – System Services (Runlevel)” then click edit.

Set the default runlevel to “3: Full multiuser with network” and then click ok.

Custom Scripts

You can use AutoYast to install custom files. This allows you to copy down configuration files to the installed machine, inject ssh keys whatever your imagination lets you do.

The other part is Post Install scripts which run during installation, this is used to run custom installers (ie wget a custom module and compile, or rsync webfiles, etc).

Finishing Touches

The final thing to do is decide if you want the autobuild script to require confirmation, by default the installer will show you the proposed setup before installing requiring you to actually click the install button, if this is how you want it then by all means have a look at the other configuration options available to you before we head into the machine installation section in the next part of the series.

If you do want everything to be automatic then goto the “System – General Options” section then edit.

Just click next on the Mouse Configuration (unless you want to change something). Then set “Confirm installation?” to off. Click Next then Finished (F10 in CLI mode).

You can download my sample AutoInstall file – Demo SUSE AutoInstall XML File

The password set on the root account in the XML file is “crackme”.

And your done. Check back for the next part when we look at actually doing a machine install.

Part 3 – Putting it all together and installing a server

In this three part series we will explore creating a repository for use with multiple systems, creating and customizing the AutoInstall file, and finally running through an install procedure.

Part 1 – Creating a repository for use with multiple systems

In this part we will look at creating a local install repository for use with installing OpenSUSE. This can be done in several ways, one from the CD/DVD or with an RSync’ed copy of the repository.

1. You will need to find a location to store your local repository with sufficient free disk space (my repo is currently 38gig’s and growing with every release and service pack that I am using. As an a-side the current full OpenSUSE11.1 repo is 14gig’s).

2. Choose a method for sharing your repository, for this guide we will be setting up HTTP with apache but you have the option of SLP, FTP, HTTP, NFS, SMB (Setting up the other methods are outside the scope of this tutorial, but whichever method you use, most of the steps will still apply).

3. If you are using Suse simply create an autoyast.conf file in the /etc/apache2/conf.d directory with the following contents (a vhost would work well for this as well, but just change the config to suit your needs).

    Alias /autoyast/ /var/lib/autoinstall/repository/

        Options +Indexes +FollowSymLinks
        IndexOptions +NameWidth=*

        Order allow,deny
        Allow from all

4. The quick an easy option here would be to just copy the contents of your installation DVD into a sub directory ie /var/lib/autoinstall/repository/opensuse11.1

The second and most complete option would be to rsync a copy from a mirror. This can be achieved with the following command.

rsync -a -v -v --delete-after --progress \
mirror.internode.on.net::opensuse/distribution/11.1/repo/oss/ \
/var/lib/autoinstall/repository/opensuse11.1/

This command will copy 14gb’s of data, but as it is using rsync you can cancel it and restart it as often as you need. Be sure to select a mirror near you from the following list OpenSUSE Mirror List.

For the most part this process has been successful with just a copy of the installation media. OpenSUSE 11.1 is the first time I have created a local mirror of the installation repository. If you are only using one architecture then coping the installation media is probably the easiest method, but if you need to install across different platforms then copying an rsync mirror would probably be the best option.

Watch out in the next couple of days for the second part in the series, Creating and customizing the AutoInstall file.

Part 2 – Creating and Customizing the AutoInstall file
Part 3 – Putting it all together and installing a server

My main objective when I started looking into disk monitoring was to get some similar stats into Cacti for Linux that can be found with the Windows PerfMon utility. I found Mark’s post and didn’t quite like the way it used cron to collect its statistics, and wanted something that I could easily add to snmpd.conf without needing to change much more. I was also keen on obtaining the mount point data for each partition as looking at “cciss/c0d0p3″ doesn’t mean as much to management (and sometimes to me) and hopefully “/home” does.

So I wrote a script which uses the output from “df -l”, “vmstat -d”, “iostat -dk”, “iostat -xdk” to produce the results I wanted. This script only looks at the individual partition on the disk. Some of the stats don’t work with Software RAID, and some stats are missing for some older versions of the kernel when used with a HP Hardware RAID card (this is all I have tested with). These are the results.

Requirements:

• sysstat package
• Net-SNMP
• Tie::IxHash perl module
• Cacti (Ver 0.8.7d minimum)

Installation:

1. Make sure you have the requirements installed.
   Tie::IxHash comes as a package on both Debian/Ubuntu and OpenSUSE and at the very least you could install it using CPAN.
   Sysstat also should come prepackaged for most Linux Distros.
2. Copy the “disk_stats.xml” file from the archive into the “resource/snmp_queries” folder of your Cacti installation.
3. Copy the “disk_stats.pl” file to your “/usr/local/bin” directory and run “chmod +x /usr/local/bin/disk_stats.pl“.
4. Edit your “snmpd.conf” file and add the following line “pass .1.3.6.1.4.1.2021.51 /usr/bin/perl /usr/local/bin/disk_stats.pl” (If that OID conflicts with another OID on your system you need to change the value used both in your snmpd.conf file and in the disk_stats.pl file. You will need to restart SNMPD after this change.
5. Import the “cacti_data_query_snmp_-_disk_stats.xml” file into your Cacti installation using the “Import Templates” menu option.

You should now be able to open a device and add the “SNMP – Disk Stats” in the “Associated Data Queries” section.

Download:

• Monitoring Linux Disk Stats with Cacti

Pings/Latency was great at around 35ms from home, but when you were logged into the server sometimes the most basic operation (ls for instance) would take seconds to complete.

So i bit the bullet and went for an overseas VPS from Linode, I went with the Linode 540 which with 540mb RAM, 24Gb Disk and 300Gb network transfer is much more then I need at the moment (All for less then what I was paying for my Australian VPS).

I have to say I am very impressed. Along with my VPS, i get free access to Linode’s DNS servers to host what seems like an unlimited amount of domains. This means I don’t have to worry about Primary/Slave’s and redundant configurations/Bind security issues. Linode also provide an API to access server stats as well as manage DNS configurations, this has allowed me to create some cacti graphs based on Linodes Stats (CPU Load over Time and Network Transfer and Allowance) which I will post later on.

Support is top notch, I had a configuration error on my server (my fault, not theirs) and logged a support ticket at about 11pm on a Saturday night (Australian Time) and within 5 minutes had a response and another 5 minutes after that the entire issue was solved.

So to anyone thinking of getting a VPS for their hosting requirements or as a test server give Linode a go. I cant fault the performance of the box or the services/support offered.

If you are interested please click on the following referral link:

• Linode.com – Xen VPS Hosting