The Hosting Specialists

by: Diego Montalvo

Since I began using FreeBSD 4.x, I quickly learned of Webmin, a web-based server administration tool, which allows administrators to manage everything from: Mysql, Apache, Sendmail, system processes, networking and much more. One of the coolest features of Webmin is it’s modular structure. Modules can easily be downloaded and installed to fit your specific server needs. In this quick tutorial you will learn how to install and use Webmin.

Accessing Webmin via a Web Browser
After Webmin has been configured you can now access your FreeBSD server using your favorite browser: http://yourserver.com:10000 or https://yourserver.com:10000 (if you opted for the SSL option). You can now login with the username and password you selected during the webmin configuration process.
Figure 1. Login Screen from a Browser

Using Webmin
Once your user credentials are authenticated you will be able to explore the simplicity of Webmin. Everything in Webmin is straight-forward since functionality is divided into specialized modules.
Figure 2. Webmin Modules

Using the MySQL Module
The MySQL database module can be used to create/ drop databases, add/ delete users, adjust privileges, db back-ups and more.
Figure 3. MySQL Module Home

System Module
The system module allows the server environment to be rebooted/ shutdown, change passwords, view running processes, change passwords, schedule Cron jobs, manage users and much more.
Figure 4. System Module (Bootup and Shutdown)

Even though Webmin will not fully replace SSH or physical access to your server. Webmin will allow you as the admin to manage and perform the most common server tasks easily via a web browser. Happy Webmin-ing!

Much of the internet connectivity in and to the Continental United States including our two datacenters was degraded by an outage within the Level3 Communications backbone that began at approximately 17:22 1 August 2011 UTC.  The impact of this event was felt not only on the Level3 backbone but also on other carriers as providers shifted large amounts of traffic that would have normally transited the Level3 network onto alternate network paths, causing increased latency, congestion and packet loss.

Many providers who utilize Level3 Communications for transport services, both telephone and IP,  were also impacted as these transport services utilize the same converged backbone as the Level3 transit product.

The Level3 Communications master case number is 40976066.

The Level3 Communications official statements regarding the unscheduled network event are:

8/1/11 7:12:56 PM GMT The IP NOC reports that the network equipment self
restored, resolving the routing issue and restoring services at
approximately 17:55 GMT. The IP NOC states that they will continue to
work with Level 3 OPS Engineers and the equipment vendor to isolate the
root cause of the service interruption. The Level 3 TSC has confirmed
that all customer services have been restored and the IP NOC will
continue to monitor for stability.

8/1/11 6:29:26 PM GMT The IP NOC reports that a routing issue failure
between Dallas, TX and Los Angeles, CA is impacting IP services in
multiple markets. The IP NOC has engaged the equipment vendor, as well
as Level 3 OPS Engineers and continues to investigate to isolate the
issue at this time.

If you have anymore questions about this outage, please contact our support team at support@rootbsd.net.

The following was done with FreeBSD 8.2-RELEASE.

CVSup is a highly efficient way of distributing files. It works similar to rsync, but was specially designed for use with CVS repositories.

Requirements:

• 5.4 GB disk space ( an additional 10-20% more free space is recommended)
• >= 2GB RAM
• A decent CPU as CVSup can be CPU intensive
• A fast disk subsystem (RAID highly recommended)
• Good network connection

Building your own CVSup mirror is made easy by the port net/cvsup-mirror.

# cd /usr/ports/net/cvsup-mirror

# make install clean

You will be prompted for a master site for you updates. Choose a mirror from the CVSup Sites list .

Follow the instructions  (Note: If you would also like to mirror the WWW data, this is a very easy way to do it.  Select ‘y’ when prompted):

I am going to ask you a few questions so that I can set up your
FreeBSD mirror configuration.  Every question has a [default]
answer.  To accept the default, just press ENTER.

At this point, I am just gathering information.  I will not touch
your system until you type “make install”.

Master site for your updates [cvsup-master.freebsd.org]? cvsup9.us.FreeBSD.org
How many hours between updates of your files [1]? [Enter]

Now you must decide which sets of files you wish to make available
from your mirror site.  You can choose any combination, and you
can put each set anywhere you want to on your disks.  Although each
set is optional, we strongly encourage every mirror site to carry
at least the main source repository.

Do you wish to mirror the main source repository [y]? [Enter]
Where would you like to put it [/home/ncvs]? [Enter]
Do you wish to mirror the installed World Wide Web data [y]? n
Do you wish to mirror the GNATS bug tracking database [y]? n
Do you wish to mirror the mailing list archive [y]? n

Now, a few questions so that I can set up your CVSup server properly.

For security reasons, both the CVSup client and server should run
under their own unique user and group IDs.  These IDs should have no
special access privileges.  Normally, the user:group “cvsupin:cvsupin”
is used for the client and “cvsup:cvsup” is used for the server, but
you can choose other names if you wish.  At “make install” time, I
will create the users and groups, if they don’t already exist.

Use unique user and group IDs for these.  Do not use “nobody”,
“nonroot”, or “nogroup”.

Unique unprivileged user ID for running the client [cvsupin]? [Enter]
Unique unprivileged group ID for running the client [cvsupin]? [Enter]
Unique unprivileged user ID for running the server [cvsup]? [Enter]
Unique unprivileged group ID for running the server [cvsup]? [Enter]

The CVSup server does its logging via syslog.  At “make install”
time, I will set up the logging for you, if necessary.  I will use
the “!program” feature of syslog to keep your CVSup log messages
separate from the messages of your other daemons.

Syslog facility for the server log [daemon]? [Enter]

You can control the load on your machine by limiting the number of
clients that the CVSup server will serve at once.  CVSup won’t load
your network especially heavily, but it is more CPU and disk
intensive than most other file server software.

Maximum simultaneous client connections [8]? 10

Later, it will prompt you again with more questions:

You need a group “cvsup”.
Would you like me to create it [y]? [Enter]

You need a user “cvsup”.
Would you like me to create it [y]? [Enter]

You need a group “cvsupin”.
Would you like me to create it [y]? [Enter]

You need a user “cvsupin”.
Would you like me to create it [y]? [Enter]

Would you like me to create cvsupin’s home directory (/home/cvsupin) [y]?

The port should now be installed and ready for configuration.

First, comment out the line added to /etc/crontab. You can adjust the time for the update to script to run if you desire:

# vi /etc/crontab

There should be a line that looks similar to this:

#6    *    *    *    *    root    /usr/local/etc/cvsup/update.sh

If you would like to further restrict access you can configure your cvsupd.access file:

# vi /usr/local/etc/cvsup/cvsupd.access

Below is what should be there originally:

-0.0.0.0/0      10      # Limit total connections
-0.0.0.0/0/32   1       # Allow only 1 connection from each host
+0.0.0.0/0              # If we reach this rule, we let the client in

Now you should be ready run your first update. This will take some time as it downloads the entire repository.

# /usr/local/etc/cvsup/update.sh

Once that is done, uncomment the line in /etc/crontab.

Add a line to /etc/rc.conf for cvsupd:

# vi /etc/rc.conf

cvsupd_enable=”YES”

Then start cvsupd:

# /usr/local/etc/rc.d/cvsupd start

Your CVSup mirror should now be working!

Other notes:

CVSup requires incoming connections on port 5999 so add a firewall rule if necessary.

If you encounter trouble, check /var/log/cvsup.log and /var/log/cvsupd.log .

– Rob Lampe

“Help! The website is down! The server is down! The Internet is broken! Help!!!” If you’ve ever been on the receiving end of this panicked cry for help, you might read this quote and identify with my feelings of frustration. I’ve gotten this phone call so many times, and while I know the website or web server might actually be “down” and the Internet connection might be “broken”, neither is probably the case. Generally, what’s happening is that the user is opening a web browser, and the web page they are trying to access is not responding for some reason. In my experience, it seems that the server is rarely, if ever, down, and even more rarely is the Internet connection failing. If you’ve been blessed with the job of handling such support requests, I’m sure you have some techniques in your tool belt that you use to run through your troubleshooting process. In this article I am going to speak about one of my most trusted and essential tools – the Unix shell account. If you’re looking for an introduction to Unix, this article isn’t the one. This article is more of ode to the shell account, one of the last vestiges of an era when computing wasn’t all buzzwords and marketing, and the power of a computer wasn’t hidden beneath a bedazzled interface.

Even in 2011, a time when computers are in our pockets that can act at the swipe of a finger or simple words spoken from our lips, the Unix shell, with its antiquated command line interface and cryptic commands, is still one of the most reliable and essential tools to aid in troubleshooting. How could this be? How could access to a 40 year old operating system account be relevant in this era? It’s quite simple actually, and while it may seem self deprecating, it all boils down to this: sometimes the best computer to use for testing and troubleshooting is a computer that is not your own. In fact, I’ve learned that it’s better if the computer isn’t even on your network. Why not your computer on your network? Because there’s a chance that whatever is happening is your fault to begin with, and it’s nice to know there’s a computer that there’s essentially no way you could have messed up!

It might be hard to face this fact, but if you, like me, are a “tech / admin / programmer / the one people call when things need fixing”, then you’ve probably had a hand in the installation and configuration of your own machine and possibly even the network at your office. You’re smart – no, brilliant! You think on your feet, outside the box. You plan ahead. You’re clever. You multi-task. The truth is that all of these attributes you possess can be liabilities, just as much as they can be qualities. Take for example the following anecdote, which may have happened to me, or to you:

Joe is a support tech. He get’s a ring on the phone from Sara – “Hey, so I opened my web browser and nothing’s happening.” Having heard this a million times, Joe replies, “What do you mean nothing’s happening? What page are you trying to get to?” Joe knows the Internet isn’t down, he’s been reading reddit all morning, or rather, working diligently all morning… So he opens a browser and tries to access the URL the caller can’t reach, “www.youremployer.com.” This can generally go a couple of ways at this point: If Joe can access the site, Sara is probably having some kind of issue local to her machine, but in this case, Joe can’t access the site either. So what now? Joe calls another staff person, the tech-savvy receptionist, Sherine. It turns out that Sherine can’t access the site either. Interesting. At this point there are 3 known machines that can’t access the site. This could be really bad. Is the server down? Joe’s starting to feel a sense of urgency here (He never panics.). What Joe doesn’t know yet is that the server is up, but there’s a local DNS problem. A problem he caused, by implementing a clever fix while “cleaning up the DNS server.” Luckily for Joe, he has a shell account, so the next step he takes is to log in to his remote shell, fire up Lynx, and access www.youremployer.com. The site is up, so it must be a local network issue. It only takes Joe a few minutes to figure out what’s really going on, because his shell not only has a web browser, but has DNS lookup utilities, and entire set of Unix power tools that he could wield. A bit of dig and nslookup and it’s revealed that the local DNS server on his network had a typo in the new www alias that he added. 5 minute fix.

This could have been much worse. Joe’s friend, Mark doesn’t have a shell account. A few weeks ago, he faced a situation like this and the only way to test from outside was to call his buddy Larry and see if he could open a browser and try it from his office. These days, Larry is so busy that he probably won’t even be able to pick up his phone. It might seem like a fringe case, but believe me, it’s not uncommon that the issues that arise day to day on your network are caused by the same techs who are charged with resolving them. Mark could be at it for hours before finding the problem, because Mark assumes that everything on his office desktop and office network are guaranteed to be in perfect working order. Mark doesn’t see the connection between the clever hack he implemented on Tuesday morning last week, and the “that’s weird” problem he’s facing on this sunny Friday afternoon (And if he doesn’t solve it soon, means missing happy hour!). These are the times when having a shell account are so handy. The techs at my office all have a hand in our network environment and server configuration. It’s our house, and we all pitch in to take care of it. None of us are ever doing one thing at a time (Who can get away with that luxury?) and mistakes happen. Often, the results of these mistakes don’t surface for some time after they’re made, which makes finding the cause even harder. If you have a trusted machine on a trusted network that you can rely on, it makes life so much easier.

Today, there’s a lot of talk about “the cloud.” What is the cloud? We’re familiar with the cloud, because there’s usually a cloud on our network diagrams – it’s the Internet. What’s so good about the cloud? Why would someone want to, for example, keep their music collection on some cloud service, instead of having it all on their local machine? It’s not hard to see why – there’s just less responsibility involved in keeping it working. We can generally trust that the folks at Amazon aren’t going to accidentally erase the hard drive, or kick the plug out of a switch, or select shutdown instead of restart when trying to reboot the server remotely. The odds are that the “server” will be up, and since you can’t get your brilliant hands on that server, there’s little you (or your brilliant colleagues) could do to ruin it. So we trust our email to the cloud, our documents to the cloud, our photos and music to the cloud. Some of the younger generation doesn’t realize that before the cloud was something spoken about in an IBM television commercial, and before most of us could afford a server of our own, one could access a powerful server, on a trusted network, for little or no cost. Shell accounts are the original cloud computing.

If you don’t have a shell account, you need one. There’s really no debating this. There’s no excuse for not having at least one. A great place to start is the Super Dimension Fortress, which you can access at sdf.org. They have been offering low-cost and free shells for over 20 years – it’s what they do. Their mission, “…is to provide remotely accessible computing facilities for the advancement of public education, cultural enrichment, scientific research and recreation.” I use my SDF shell for troubleshooting, testing scripts, storing files, tunneling ssh connections, accessing IRC support channels, and just about anything else. Sure most of the time I could use my own computer, but as you may know by now – sometimes my computer is broken, because I broke it.

I’ve found that while SDF is great (and I can’t expound on that enough), there are times when I need to have root access. Sometimes I need to test some software SDF doesn’t have installed, or I need to access some privileged ports (ports numbered lower than 1024.) Here is where services from a place like RootBSD are terrific. From RootBSD you can get a virtual private server that runs Unix (even NetBSD or OpenBSD, which is not easy to find anywhere else), and you can do whatever you want with it. I recommend having a Unix VPS around, because they are indispensable for serious testing and troubleshooting. Obviously, I still recommend having a shell account somewhere else to test from, and by now I hope you’ll agree that it’s sensible. Let’s just hope the Internet isn’t really broken…

– Michael Hernandez

We have decided to upgrade our virtual hosting plans to include more backup space. All new backup accounts will be provisioned with the new quotas; all current customers are eligible for a free upgrade by contacting our support team at support@rootbsd.net. An upgrade will only modify your quota for your account so your ssh details will not change.

The quotas are now as follows:
Iota = 20GB
Lambda = 30GB
Omicron = 40GB
Sigma = 60GB
Omega = 120GB

Additional backup space can also be purchased for $0.12 per GB per month.

OpenBSD 4.9 was released yesterday and is now available with all our VPS packages.

To read more about OpenBSD 4.9 release see http://www.openbsd.org/49.html.

Contact our support team if you have any questions at support@rootbsd.net.

FreeBSD 8.2 was officially released today. This release includes

• Xen HVM support in FreeBSD/amd64 and Xen PV support in FreeBSD/i386 improved
• ZFS on-disk format updated to version 15
• aesni(4) driver for Intel AESNI crypto instruction set
• BIND and OpenSSL updates
• Gnome updated to 2.32.1
• KDE updated to 4.5.5
• Other improvements and bug fixes.

All new orders will now have 8.2-RELEASE unless otherwise specified. For existing customers, you can update your system using the following:

# freebsd-update upgrade -r 8.2-RELEASE
# freebsd-update install
# shutdown -r now
After rebooting,
# freebsd-update install

If you are updating from 7.4-RELEASE or earlier you will be prompted to rebuild all third-party applications due to updates in system libraries. Then you will have to run freebsd-update install and reboot once more.

To read the official announcement, see

http://www.freebsd.org/releases/8.2R/announce.html

All new orders are now able to select FreeBSD 8.1-RELEASE 64-bit as an option in the order form. Although manual install is still an option, this selection will prompt our new automated installer for FreeBSD 64-bit that allows your VPS to be set up in a matter of minutes like our current 32-bit offering once your order is approved. FreeBSD 32-bit is still recommended for most users.

RootBSD is proud to now offer OpenBSD 4.8 virtual hosting. Forked from NetBSD by the founder and current project leader, Theo de Raadt, in late 1995, OpenBSD is known for its quality focus on security and code correctness. Pricing options and specifications are the same as our FreeBSD virtual servers (http://www.rootbsd.net/virtual-hosting/). You can sign up today and have your VPS running in no time! Just be sure to specify that you would like OpenBSD in your order.

The time has finally come. We now have an official IRC channel over at freenode, #rootbsd. We welcome everyone to come in and chat, ask any questions pertaining to your VPS with us, or ask questions about FreeBSD in general. We always welcome friendly conversation.

We may occasionally ask questions in the channel pertaining to our products / services or any projects we’re working on to get your input. Your ideas are important to us and the #rootbsd channel will allow a great opportunity for beta testers to communicate with us real-time for any projects / products that are in development.

We look forward to chatting with you.  Feel free to stop by any time.  We encourage customers to continue submit support tickets at support@rootbsd.net for support issues, as the IRC channel will not be monitored for support.