Network Monitoring – Automated Reboot System

Posted on May 6, 2010. Filed under: Hardware, Hosting, Servers |

Bring State of the Art Network Monitoring in house – save money, offer more network monitoring options and stay ahead of your servers.

Monitor the services you need to monitor – use login’s to verify connectivity to your network services. Any network service can be checked at any interval – from every 10 seconds to every 15 minutes – whatever frequency makes you feel the most comfortable. Other network monitoring systems are based on a per unit pricing scheme – using our solution, you can monitor as many devices as you need to monitor – and you can monitor any service that is available over the network.

From SNMP to SMTP, MySQL monitoring and web site up-time, you can bring your network monitoring solution in-house – at an affordable price and with a number of options available.

Automated Reboot Systems

It’s not enough to simply monitor your servers and services – what do you do in case of a server outage, a remote site’s connection down or any of the other services you have to monitor?

Being able to control the power outlets of your servers and and network devices allows the network admin to toggle a machine off and on – resolving over 98% of server service outages.

The PowerKey Pro 600 has 6 software controlled outlets – allowing you to reboot up to 6 devices at any time. Imagine having your webserver stuck at 3 am – rather than driving to the office or data center, login to the network monitoring system from your home or office and toggle the outlet remotely.

With our network monitoring tools and automatic reboot system, you can notify the on-call technician, reboot your server and be notified the services are back on-line faster than you get your pants on and into your car.

For more info, http://edition.net/Network-Monitoring-Automated-Reboot-System

Read Full Post | Make a Comment ( None so far )

Mac OSX Server FTP Server Administration

Posted on January 29, 2008. Filed under: Hardware, Leopard, OSX, Servers, Software, Xserve | Tags: , , , , , , , |

FTP Only Accounts Under Mac OS X

The following howto describes how to set up ftp only accounts using Apple Mac’s built in ftp server (lukemftpd).

This outline requires you to use the terminal, NetInfo Manager and have admin privileges on the machine in question.

Warning: You can muck things up quite seriously using NetInfo Manager. At the very least make sure you have a recent, full back-up of the machine you’re planning to setup before going any further.

To create ftp only accounts we need to:

  1. Create an ftp login shell
  2. Restrict our prospective ftp user to their folder
  3. Create the user account
  4. Create a folder for the new user
  5. Give the user a password

Create An FTP Login Shell

To create an ftp login shell we need to copy or link /sbin/nologin to /sbin/ftplogin. We’ll create a symbolic link from /sbin/nologin to /sbin/ftplogin. To do this:

  1. Fire up Terminal
  2. Type “sudo ln -s /sbin/nologin /sbin/ftplogin” (without the quotes)
  3. Hit return
  4. Type in your admin user’s password when prompted

Now we need to add the new “shell” to the list of shells available to the system. To do this we need to add “/sbin/ftplogin” to the list of shells given in the file found at /etc/shells. In Terminal:

  1. Type “sudo pico /etc/shells”. This’ll open up the file “shells” in a simple text editor in Terminal
  2. Hit return
  3. Type in your admin user’s password if prompted
  4. Add the string “/sbin/ftplogin” (without the quotes) on a new line at the end of the list of shells available. This’ll give you a final list similar to:


  5. Type ctl + “o”. That’s the letter “o” while holding down the control key
  6. Hit return
  7. Type ctl + “x” to eXit Pico

Restrict User To Their Folder

We’re setting this up now so that as soon as the user we’re creating gains access to our machine, they’re restricted to their log-in or root folder. All we have to do is create the file /etc/ftpchroot if it doesn’t exist and then add the prospective user’s username to the file.

  1. In Terminal, type “cd /etc” (without the quotes. From here on in, I’ll assume you’re ignoring the quotes)
  2. Check to see whether the file “ftpchroot” exists. If it doesn’t, type “sudo touch ./ftpchroot” and give you admin password if prompted for it

Now we need to add the username to the created file. Using pico:

  1. In Terminal type “sudo pico ./ftpchroot”. This’ll open up the file “ftpchroot” in a simple text editor in Terminal
  2. Type in your prospective ftp user’s username. Ours is “fred”. For safety, make the username all lowercase letters only – although we’ll let you have the underscore (“_”) too.
  3. Type ctl + “o”. That’s the letter “o” while holding down the control key
  4. Hit return
  5. Type ctl + “x” to eXit Pico

Create User Account

We do this in NetInfo Manager. I’m going to talk you through doing this the long winded way – but once you’ve got one account set-up, I’d suggest you duplicate an existing account and modify it as appropriate.

  1. Fire up NetInfo Manager
  2. At the bottom of the pane, click the little lock symbol and supply your admin username and password to unlock NetInfo Manager
  3. In the lefthand column, select “/”
  4. In the middle column select “users”
  5. Click the “New” icon at the top of the pane. This will create a new user called “new_directory”.

Now we need to modify this user account to give it the properties we’re after. Some of these properties will depend on your setup and how you want to administer your machine. We’ll use some reasonable settings but you may want to change these.

Before we go further, we do need to check what the next available user id (uid) is. To do this, click through your users in NetInfo Manager (ignoring the system users if you know what these are) making a note of the highest uid. In my case it’s 503. This means that my next user is going to be 504. Alternatively, start a new series for ftp users starting at 601.

Having done this, with the user “new_directory” selected in NetInfo Manager:

  1. Select the “name” property in the bottom half of the pane. Double click on the Value “new_directory” to select it and type in your username. In our example our username, as added to the ftpchroot file is “fred” – so that’s what we’ll type here.
  2. Create a new property by clicking in the “New” icon at the top of the pane. This will create a new property called “new_property”. Change the property value to “uid”. Now change its value “new_value” to the next available uid – or, if you’re starting a new series, 601.
  3. Add a new property for the group id – “gid”. We’ll set this to “20”. i.e. Create the new property, select “new_property” and type “gid”. Select “new_value” and type “20”.
  4. Follow this procedure to add:
    Property Value(s)
    expire   0
    change   0
    shell   /sbin/ftplogin
    home   /Users/<username>

    Where the text “<username>” in the last property (“home”) is the username of the user you’re adding. In our example “fred”. So the value for the property “home” would be “/Users/fred”. This means the bottom of your NetInfo Manager pane should end up looking something like:

    Property Value(s)
    home   /Users/fred
    shell   /sbin/ftplogin
    change   0
    expire   0
    gid   20
    uid   504
    name   fred

    2006-04-18: We’ve been contacted by Esben Sørensen and Antoine Durr over the weekend, both of whom make the observation that “realname” needs to be added to the properties listed here. i.e. we should end up with:

    Property Value(s)
    home   /Users/fred
    shell   /sbin/ftplogin
    change   0
    expire   0
    gid   20
    uid   504
    name   fred
    realname   Fred

    So, add the “realname” property “else the account’s system preference pane will henceforth come up blank due to an incorrect/invalid realname” (Antoine Durr).

    Thanks to Esben and Antoine.

  5. Make sure you remember the uid as you’ll need it in a sec.
  6. Close NetInfo Manager saving and confirming the save as you go.

Create A User Folder

We need to create a user folder and then change its ownership (and permissions) to reflect those of the newly created user.

  1. In Terminal, type “cd /Users”. Typing “ls” will give you a list of all the users on your machine
  2. Type “mkdir <username>” where <username> is the new user’s username. We’ll be typing “mkdir fred”
  3. Change the owner of this file by typing “sudo chown <uid>:20 ./<username>. Where <uid> is the uid for the user you added (and made a mental note of) and <username> is the username…. OK. You’ve got the idea. Oh. If your prompted for a password, give your admin password.
  4. Change the permissions of this file so that we can all access it (if you know what you’re doing here, set the permissions as you see fit). “sudo chmod 777 ./<username>”

Now we’re on the home stretch.

Give The User A Password

The next step is to give the newly created user a password. To do this, in Terminal:

  1. Type “sudo passwd <username>”. (So we’ll be typing “sudo passwd fred”).
  2. Type in the new password at the prompt.
  3. Retype it as prompted.


If you’re behind a router or firewall which does Network Address Translation (NAT), there’s one more thing. Passive FTP requires the machine offering the FTP service to return its IP address and a port on which it’ll be listening. If you’re on a NATed network, it’s likely that the FTP server is going to return its internal IP number rather than the external address you’d prefer it to give. To get around this:

Create the file /etc/ftpd.conf

Add the line “advertise all <host>” where <host> is either the host name or external IP address for the FTP server.


Restart the FTP server to ensure that all the caches are flushed and then see whether you can log-in via ftp as the new user. The easiest way of doing this is to turn FTP off and then on again in System Preferences -> Sharing.

Read Full Post | Make a Comment ( 4 so far )

Transfer Between Mac OSX Host with Windows XP Guest in VirtualBox

Posted on January 28, 2008. Filed under: Hardware, OSX, Servers, Software | Tags: , , , |

Until the latest version of VirtualBox (1.4.1) released for Mac, there are still no support for the Host Interface networking option enabled yet. Moreover, you even could not see the NIC card got working on Mac OSX running in some Intel Machine (Jas 10.4.8) since it didn’t recognized properly with the built-in driver. So, is there anyway to get a simple networking between both OS? Sure it does.

FYI, file transfer in a Shared Folders option allow you to access files of your Mac OSX system from within the Windows XP guest system, much like ordinary shares on Windows networks would – except that shared folders do not need a networking setup. Sharing is accomplished using a special service on the host and a file system driver for the guest, both of which are – fortunately – provided by VirtualBox. In order to use this feature, the VirtualBox Guest Additions have to be installed in guest OS. Currently, shared Folders are limited to Windows XP, Windows 2000 and Linux 2.4 and 2.6 guests. To share a folder with a virtual machine in VirtualBox, you must specify the path of the folder to be shared on the host and chose a “share name” that the guest can use to access it.

Then, you can mount the shared folder from inside a VM the same way as you would mount an ordinary network share.
In Windows XP guest, use the following formula command:

net use x: \\vboxsvr\sharename

While vboxsvr is a fixed name, replace “x:“ with the drive letter that you want to use for the share, and sharename with the share name specified before.

To simplify this, I used to create a batch file which can executed manually to mount all of the 4 shared folder name (1 NTFS partition for Windows XP, 2 FAT32 partition for data & 1 HFS Mac OSX partition) specified before after the guest OS shows up. For example, named it with vboxsvr.bat and the picture below is the values:

You can also create a link for the batch file & move it to on a someplace you like for example in a quick launch panel.

To test the script, simply click the shortcut file until it processed completely. If it succeeded, the script will create new networking drives available assigned next to the drive letter defined before on the batch file.

However, I still don’t understand why it marked with Disconnected Network Drive label although files & folders on both OS is accessible as you may seen on ordinary full permission shared drives.

Read Full Post | Make a Comment ( 5 so far )

Optimizing an Xserve for Web Hosting

Posted on January 24, 2008. Filed under: Apache, Hardware, Hosting, Leopard, OSX, Servers, Software, Xserve | Tags: , , , , , |

A single Xserve is ideally suited for smaller scale Web hosting, where the task is to host a handful of moderate-traffic sites. (With a fleet of Xserves, you could host an eBay or an Apple.com, but that’s a topic for another article.) The Xserve’s Apache Web server software has a multitude of configuration options. In this article, I will go over how to set up Apache to serve multiple Web sites from the same machine—so-called “virtual hosting.” I will also look at ways to optimize the server’s setup for fast, robust Web hosting. This article assumes that you have already followed the steps in the Mac OS X Server Administrator’s Guide to start Web service. (You can find the Guide on the Mac OS X Server Manuals page.)

Hosting Multiple Domains on One Server

The out-of-the-box behavior of Apache is to have one IP address and to serve one domain. However, it is quite easy to transparently host thousands of domains on a single Xserve, and the users need never know that it’s one machine behind the scenes and not a whole farm. There are two approaches to this sort of “virtual hosting”—IP-based and name-based. With IP-based hosting, each domain name is mapped to its own individual IP address. Name-based hosting uses a little trickery so that many domains can be served from the same IP address. IP-based hosting is a little more robust—it allows for secured HTTPS transactions, which are important for Web commerce, reverse DNS, and some other features; but IP addresses are scarce, so name-based hosting, which works perfectly well, is probably preferable for most applications. Name-based hosting depends on a certain header sent by the browser, and as a result it doesn’t work with some browsers released before 1997, but that is less and less of an issue as those browsers become increasingly scarce. I will go over how to set up both kinds of virtual hosting.

IP-Based Hosting

Assuming you have already acquired the domain names and IP addresses you’ll be using, the first step in creating an IP-based hosting setup is to configure the Xserve to have multiple IP addresses on the same Ethernet card. This can be done from System Preferences on the Xserve. Open the Network Preferences pane. Select “Active Network Ports” from the Show drop-down menu. Choose the port corresponding to the Ethernet card that you want to assign multiple IP addresses to, and click “Duplicate.” Then simply change the duplicate configuration to reflect the second IP address. It is necessary also to make sure that the Subnet Mask setting for all but one of the ports is This will prevent conflicts in the routing tables.

On a headless Xserve, the same thing can be accomplished with the IPAliases startup item. If the file /etc/IPAliases.conf doesn’t exist, create it. For each additional IP address, this file should contain one line of the form


For example, to add the IP address to the en0 network interface, the following line would be used:


The netmask should always be

In addition, IP aliases must be turned on, by adding to /etc/hostconfig the line


Every time the system is booted, the aliases listed in /etc/IPAliases.conf will be added. The file can contain any number of aliases.

With multiple IP addresses configured, the next step is to add DNS entries. For each domain that you want mapped to an IP address, create an A record in the DNS pointing the address to the site. In BIND, the A record might look like this:

firstdomain.com.   A

All of the records for the various domains can be in the same DNS file or in different ones, depending on the preferences of your users and whether you host your own DNS or not.

Finally, tell Apache how to deal with requests for the various addresses. In Server Settings, click Web in the Internet tab. Choose “Configure Web Service” from the drop-down menu. In the Sites tab, you can add as many sites as you like, just by entering the domain name and IP address for each one. The content for each site should be placed in the folder you specify in the “Web folder” field here.

Name-Based Hosting

Setting up name-based hosting is a bit simpler. Add DNS records for each domain to be hosted, such that each domain name resolves to the same single IP address—the one associated with your Xserve. When a user’s browser makes a request for one of the domains, it will send an HTTP Host header indicating which domain it is requesting. Apache interprets this header and returns the appropriate content.

After the DNS is configured, go to Server Settings’ Internet tab, and choose “Configure Web Service” from the Web drop-down menu. Go to the Sites tab. Here you can create an entry for each site you want to serve. Give each one the same IP address but different domain names. Content will be served from the location specified in the “Web folder” field.

If desired, name-based and IP-based hosting can co-exist.

Handling A Lot Of Domains

If you are hosting quite a few domains, or adding new ones frequently, it can be inconvenient to add an entry for each one in Server Settings. The process can be automated to a degree, so that simply adding a DNS entry and creating a new directory for content on the Xserve is sufficient to launch each new domain. NOTE that this method and that of adding sites via Server Settings are mutually exclusive—new domains added in this way will not be reflected in Server Settings, and adding or editing sites in Server Settings will alter the configuration of the automatically created domains with unpredictable results. This method also precludes turning the performance cache on and off on a per-domain basis. That said, here are the basic steps.

First, configure a single site in Server Settings, with the correct IP address. The domain name you give it doesn’t matter. Save the changes.

Edit /etc/httpd/httpd.conf to uncomment the two lines beginning:

LoadModule vhost_alias_module


AddModule vhost_alias_module

Also, change the line

UseCanonicalName On


UseCanonicalName Off

Next, edit /etc/httpd/httpd_macosXserver.conf. There should be a long comment section starting with the line:

## The section below contains a block for each site (virtual host).

Below this comment section is the stanza to edit. It looks something like this:

#<RAdmin 100>NameVirtualHost



#WebPerfCacheEnable Off

#SiteAutomaticallyDisabled Off

ServerName example.com

ServerAdmin webmaster@example.com

DocumentRoot "/Library/WebServer/Documents/"

DirectoryIndex index.html index.php

CustomLog "/private/var/log/httpd/access_log" "%{PC-Remote-Addr}i %l %u %t \"%r\" %>s %b"

ErrorLog "/private/var/log/httpd/error_log"

and so on.

The stanza may look somewhat different if performance caching is enabled.

There are just a few changes to make to this. First, on the ServerName line, you can place the fallback domain to which users of pre-1997 browsers will be sent. This line has to exist, but for users of modern browsers, it will be ignored.

Then modify the DocumentRoot line to look like this:

VirtualDocumentRoot /Library/WebServer/Documents/%0

and the CustomLog line to include %v :

CustomLog "/private/var/log/httpd/access_log" "%v %{PC-Remote-Addr}i %l %u %t \"%r\" %>s %b"

Save the file and restart Apache.

The VirtualDocumentRoot directive tells Apache to interpolate information from the server name, which in this case is read on the fly from the user’s browser, into the pathname. “%0” is a specifier representing the requested domain name. Thus, a browser request for http://domain-ten.com/index.html will be answered with the file at /Library/WebServer/Documents/domain-ten.com/index.html.

As a result, to host a new domain, all that has to be done is to create a new directory corresponding to the domain name in /Library/WebServer/Documents, and to place content to be served in that directory.

The various specifiers understood by the VirtualDocumentRoot directive are explained on the apache.org website. For example, if you have hundreds of domains hosted, they can be sorted into 36 directories based on their first alphanumeric character with the following directive:

VirtualDocumentRoot /Library/WebServer/Documents/%1.1/%0

A side-effect of this aliasing technique is that log data for all the virtual domains is sent to the same file. Adding the “%v” specifier to the CustomLog line prepends the name of the domain to each log line. A simple script can be used to parse this master log file into individual files for each domain, if so desired. More information on CustomLog specifiers is available on the apache.org website.

Tuning Web Server Performance

When setting up an Xserve for use as a Web server, there are a number of things you can do to improve performance. Some of these techniques improve the performance of the machine in general; others involve examining where bottlenecks may be occurring and tuning the Web server to work around them.

First, it is important to make sure the hardware is up to speed. Even a low-end Xserve has a very nice feature set, including fast disk access, fast Ethernet, and a minimum of 256MB of RAM out of the box. The RAM allotment can be increased to 2 gigs: if the Web server at full-throttle seems to be using a lot of memory, buying more RAM could speed things up considerably. In terms of hardware, there are several options that will increase reliability, including IP failover to a second server, which is described in detail in the Admin Guide, and adding an Xserve RAID for ultra-fast and reliable storage.

In addition to the hardware approaches, there are a number of software-based strategies for optimizing a Web server. I will detail some of these below.

Apple’s Performance Cache

Included in the OS X Server installation is Apple’s performance cache. This acts as an intermediary between the Apache Web server and the user: the cache stores a copy of commonly requested pages from the sites served, and, upon receiving a user request for one of these pages, sends it along. This involves much less overhead than invoking Apache each time the page is requested. Apache is still kept busy serving dynamic and less common pages. The cache can be enabled and disabled individually for each of the sites served from the machine. In general, the cache is very helpful for highish-traffic sites that consist primarily of static HTML pages. The total size of the site’s popularly requested static pages should be small enough to fit in the machine’s RAM; otherwise caching may actually slow things down. For sites with primarily dynamic content, the cache will not be helpful.

To turn the performance cache for a particular site on or off, go to the Internet tab in Server Settings and click Web. Choose “Configure Web Service,” and then select the Sites tab. Edit the site you want to change, and go to the Options tab. Check or uncheck “Enable performance cache” and save. The changes take effect when the Web server is restarted from the Web drop-down menu. Note that this cannot be done with a server configured with dynamic site addressing, as explained above.

Aspects of the behavior of the cache can be configured in the file /etc/webperfcache/webperfcache.conf. The default settings seem to work quite well, but they can be adjusted to make the cache work better with tweaked Apache settings (see below) or unusual server configurations.

Tweaking Apache

Apache has various settings which control how it handles requests. Tuning these can make a big difference in the performance of the server.

Apache’s performance can be monitored by viewing yourhosteddomain.com/server-status in a browser. Configure the <Location /server-status> section in /etc/httpd/httpd_macosXserver.conf to control who can view the status: it’s set by default to deny all but localhost.

Eliminating Unnecessary Modules

The first step in speeding up Apache is to remove any unnecessary modules. To see which modules are compiled in, do the following:

In httpd.conf, there is a section that looks like this:

#<Location /server-info>#    SetHandler server-info

#    Order deny,allow

#    Deny from all

#    Allow from .your-domain.com


Remove the # from the beginning of each line to uncomment the directive. Change “.your-domain.com” to the actual domain(s) that you wish to access server information from, and then restart Apache.

Now http://yoursite.com/server-info should display a variety of detailed information about the server, including which modules are compiled in, and configuration information for each module.

Modules that are compiled in statically can’t be removed without recompiling the Web server. The out-of-the-box configuration of Apache on Xserve has almost every module compiled as dynamically loadable, so it is easy to turn off unnecessary ones without recompiling the Web server. Dynamic modules are loaded when Apache starts, according to the LoadModule and AddModule directives in the file /etc/httpd/httpd.conf.

The base installation of Apache that ships with OS X Server loads quite a few dynamic modules by default. Each of these takes up some memory, and some of them, such as mod_status, cause Apache to do extra work with every request. Any modules that aren’t necessary to the functioning of the sites you host should not be loaded. This can be controlled by commenting out (by prefixing a # on each line) the relevant LoadModule and AddModule directives for each module in /etc/httpd/httpd.conf. Every module has both a LoadModule and and AddModule directive—be sure to comment out both when disabling a module. Mod_include and mod_rewrite, among others, are notorious performance hogs.

Adjusting Processes

There are several directives that can be adjusted to modify how Apache handles traffic. Apache will spawn new versions of itself to handle requests. MaxClients sets the maximum number of these that will be spawned. The more of these there are, the faster Apache can handle a large number of requests—up to the limitations of the machine’s memory. The default is 500. Figure on about 1 MB of RAM for each httpd instance, and set MaxClients accordingly in Server Settings (or /etc/httpd/httpd_macosXserver.conf).

The MinSpareServers and MaxSpareServers directives, in /etc/httpd/httpd.conf, set how many spare server processes are running to handle sudden requests. StartServers sets how many are created when Apache first starts. You may want to increase StartServers and MaxSpareServers if Apache seems to be slowing down when it has to create new processes. When Apache spawns more than four child processes per second—a sign that it may need more spare servers—it logs that fact to its error log. Keep an eye on the log and tune if necessary.

MaxRequestsPerChild keeps a lid on potential memory leaks by killing off each child process after it has served a certain number of requests. The default setting on OS X Server is 100,000, which is reasonable. A setting of 0 means that Apache’s children are never killed.

The KeepAlive settings in /etc/httpd/httpd_macosXserver.conf control how each server process listens for new requests on a connection that has been established. Increasing KeepAlive requests reduces traffic from new connections, but increases server load with many Apache processes waiting around for orders.

Removing Extra Steps

Another key to speeding up Apache’s behavior is to minimize the number of things it has to do for each request. If the Web server is receiving a lot of requests, these extra tasks can bog it down tremendously.

HostnameLookups causes Apache to perform a DNS lookup for every incoming request, so it can log the domain name as well as the IP address in the access log. This should be turned off, as it is by default, if performance is an issue. The DNS lookups can be performed after the fact, on another machine, using a tool such as logresolve.

If AllowOverride is turned on, then Apache checks for the presence of .htaccess files containing overriding directives at every level of the hierarchy. This repetitive checking eats up server resources. For maximum performance, set AllowOverride None. (This is the default setting for OS X Server.)

FollowSymLinks is a directive that instructs Apache to follow symbolic links without performing an additional security check on them. If this is turned off, Apache slows down to check each symbolic link.

Finally, logging is very important for 95 percent of Web-hosting activities, but if you are not using it, turning it off will improve performance. All that file access slows things down considerably. Set TransferLog /dev/null in /etc/httpd/httpd.conf.

Temporary Adjustments

Sometimes, if you’re lucky, you have advance warning of a peak in Web traffic; say, a well-read news site is planning to link to one of the domains you host tomorrow. There are a few emergency preparations that can be made to allow for that kind of situation.

First, free up memory and CPU by offloading everything you can. If the Xserve is acting as a mail server, database server, or what-have-you, as well as a Web server, move those duties to another machine if possible. If there are other medium-traffic domains that could be hosted elsewhere temporarily, do it. Shut down unnecessary processes and cron jobs.

Second, make sure you have enough bandwidth. If you use a firewall, you may want to reconfigure its socket handling to maximize throughput.

If it is possible, making changes to the content of the
domain to be served can be very effective. Remove images, reduce
their file sizes, or simply move them to another server and
serve them from there.

Apache’s MaxClients limit is hard-coded at 2048 in OS X
Server. For peak traffic, you may want far more clients than
this. It is necessary to recompile Apache to make this change.
You will have to download the source code from the
href=”http://httpd.apache.org/download.cgi”>apache.org website. In the source file src/include/httpd.h,
change the line

#define HARD_SERVER_LIMIT 2048


#define HARD_SERVER_LIMIT 4096

Or whatever number seems appropriate. Note that the number given here is usually a factor of 2.

Then recompile according to the instructions in the INSTALL file included with the source.

Careful deployment of all of these tips should significantly improve the way the Xserve handles Web serving. If, after all of the above, your server simply can’t handle the load it’s getting, that’s when you should consider adding a second machine to share the burden.

Read Full Post | Make a Comment ( 4 so far )

OSX Wiki Server

Posted on January 23, 2008. Filed under: Hardware, Leopard, OSX, Servers, Software | Tags: , , , , |

Mac OS X Server Wikis and Blogs Screenshot

Wiki Server. Collaboration for teams.

Mac OS X Server makes it easy for groups to collaborate and communicate through their own wiki-powered intranet website complete with group calendar, blog, and mailing list. Users can create and edit wiki pages, tag and cross-reference material, upload files and images, add comments, and search content with point-and-click ease.

Communication is key.

Whether it’s a small business or a workgroup inside a large corporation, all members need access to the same materials in order to work effectively. Wikis assist users in the clear exchange of information, eliminating confusion and ensuring that all members of a project have access to the resources they need.


The wiki blog is the perfect place for sharing team news and status reports or encouraging brainstorming. For shorter comments, there’s a space at the bottom of the wiki page where users can share their thoughts or provide feedback. You have the ability to control who can add comments — nobody, only authenticated users, or anyone who has access to the wiki. Teams can also use the wiki for file exchange — uploading shared documents, images, or movies for distribution; even tracking revisions on documents. And shared calendars help users stay on track by ensuring that everyone can see meeting schedules and milestones.

Wikis and Blogs editing icons

Customized web workspace.

Wikis allow you to create custom, project-specific websites. Select from 20 built-in themes with different colors, fonts, and layout styles. You can customize these templates with your own banner image and a custom sidebar title that displays pages with a user-defined tag at initial login. Once set up, it’s easy to add, delete, and edit content in whatever way makes sense. No syntax or markup knowledge is required — what you see on the page is exactly what you get.

Wiki Server showcase

You can insert hyperlinks, link between pages, add images, attach files, and change formatting — all with a few clicks. Because wikis feature RSS support, team members can easily track changes and be notified when new content is added, edited, or tagged.
Wikis RSS icon
You can subscribe to RSS feeds for the entire wiki site, any individual page, or any tag or search results. And you’ll never have to worry about making mistakes. Since the wiki maintains a complete history, you can always revert to a previous version of your document.

Once you create a wiki website and give access to members of the workgroup, everyone has the same capability to contribute to the site. And it’s not limited to text and images — users can access a group calendar to track meetings and deadlines or send messages to a mailing list to keep others informed. The blog feature is perfect for brainstorming or commenting on work. And there’s an option for subscribing to a podcast — so anyone who missed that important conference call can catch up on the news.

Read Full Post | Make a Comment ( 1 so far )

Leopard Server

Posted on January 22, 2008. Filed under: Hardware, Leopard, OSX, Servers, Xserve | Tags: , , , , , |

Setup and Administration. No IT department required.

If you think it takes a dedicated IT department to deploy and use a server, think again. Leopard Server is designed so you can easily set up and manage servers.

Server Preference Icon

Keeping it simple.

Leopard Server builds on Apple’s legendary ease of use with new Server Assistant and Server Preferences features that allow even nontechnical users to set up and manage a server in just a few clicks.

Server Assistant walks you through the setup process and configuration of essential services. It runs a built-in Network Health Check to verify network settings and Internet connectivity.

Using the new Server Preferences application, you can quickly manage users and groups on the server and set up key services such as file sharing, calendaring, instant messaging, mail, websites with wikis and blogs, virtual private networking for remote access, and backup settings for network clients.


Server Status Widgets

Status reports.

To help you keep an eye on things, a new Server Status Dashboard widget provides an easy and instantaneous way to monitor your server. You’ll get at-a-glance information on the status of essential services such as mail, file and printer sharing, iChat, and more.

Setup and Administration showcase

The end of manual labor.

Adding clients to the network is now a quick and easy process. Just plug the new Mac into the network and launch the Directory Utility application. It will automatically detect and sign on to the server. After authenticating, the new computer will be configured to use the services offered by your server, and all your applications, such as Mail, iChat, and iCal, will also be configured and ready to use. Leopard Server will keep these settings updated, so you’ll never need to manually reconfigure a user’s account or computer again.

Server Admin for advanced IT services.

Server Admin

Advanced IT administrators can use Server Admin to set up, manage, and monitor advanced services. Completely redesigned in Leopard Server, Server Admin includes new file-sharing and permission controls, tiered administration, and options for organizing servers into smart groups.

Smart Groups

Read Full Post | Make a Comment ( None so far )

  • Blog Stats

    • 160,358 hits
  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 21 other followers

Liked it here?
Why not try sites on the blogroll...