Top 5 Benefits of Using a Gentoo Linux Operating System

gentoo linux 300x300 Top 5 Benefits of Using a Gentoo Linux Operating System

Do you get adrenaline rush by just being on the bleeding edge of programming or computing? Is your dream computer experience filled with images of you customizing every aspect of your operating system? If so, Gentoo Linux operating system is the ideal distribution for you.

Gentoo Linux is a free and open source operating system that allows the user to compile the source code depending on the selected configurations. This feature greatly improves overall system efficiency since the computer is not overburdened with unnecessary programs, and executable programs are optimized to suit the user's exact needs. However, because of the long hours needed to compile the source codes, this operating system is not suited for programming greenhorns.
Continue reading

Apache MPMs – Prefork, Worker, and Event

3trz5s 224x300 Apache MPMs   Prefork, Worker, and EventIf you're still using Apache when the world is slowly moving to NGINX, you're looking for every optimization to keep up as much as you can. You might tweak what modules are loaded, play with Keepalives, fiddling with Negotiations, FollowSymLinks, and Overrides, you might even be throwing more hardware at it and pretending you didn't. However, if you're running a ridiculously busy site and don't want your web server to topple over due to memory usage, you should really look into what MPM you're using.

The MPM, or Multi Processing Module, you use is responsible for just about the entire HTTP session. From listening on the network, taking requests in, and most importantly, how to handle children. No, we're not talking about 5 year olds, we're talking about child processes and threads. For Unix based machines, Apache offers three MPMs to choose from; Prefork, Worker, and Event. While there are many other MPMs available for Apache on different systems, we're going to focus on Linux and what you're most likely going to see (and what I have experience with). These MPMs handle the processes and potentially threads that the Apache web server uses to accept, process, and server HTTP requests.

Continue reading

Apache Worker, I Command Thee!

If you're running a web server, no matter the traffic, you've most likely looked at pretty graphs from your server and turned into a efficiency nut of some kind. You're always looking at what is using your RAM, what's eating up your CPU, and what's clogging up your network. If you're not, you should be! While there's tons of tips, tricks, and techniques you can apply to your server to run your software stack as efficiently as possible, KeepAlives settings in Apache are something that many people overlook and can have a dramatic impact on Apache's memory usage. We're really only going to focus on two Apache directives found in your main Apache configuration file.

On Debian/Ubuntu = /etc/apache2/apache2.conf
On RHEL/CentOS = /etc/httpd/httpd.conf

KeepAlive (On | Off)
KeepAliveTimeout (# of seconds to stay alive before timing out)

In short KeepAlives are a way for Apache to process multiple HTTP requests over a single TCP connection. This can help serve your files quicker by the client (visitor's browser) and the server (Apache) not having to reestablish a new TCP connection for each and every file on your web page. Although, if used improperly, this can hurt your server by keeping these connections open longer than they need to be and causing unnecessary memory usage by your server. This memory usage is what we're going to tackle a bit with KeepAlives.

Continue reading

Command Line Basics Part 2: Unix File System

In the most recent post in this series I talked about the commands you use to move around the file system. Now I'll look at some of the places you might want to go.

Linux (and other Unix-like operating systems) inherited their file system layout from a long history going back to the original Unix incarnations in the 1970s. Over time various versions changed where things were located. The Filesystem Hierarchy Standard is an attempt to standardize this. It probably doesn't cover all Linux/Unix installations perfectly, but it's a fairly good guide of where stuff is in a modern installation.

The most common place you'll visit when administering a system is the /etc directory tree. That's where the configuration files for applications installed on the system reside. So if you need to change an application setting, you'll go to that application's configuration directory under /etc. For instance, if you have a web server, the configuation files will be under /etc/apache2. Here's a listing of the contents of that directory:

2012 08 13 1045 Command Line Basics Part 2: Unix File System

The right column in this display is the name of the file or directory. The first character is "-" for files and "d" for subdirectories. apache2.conf has basic setup for the apache web server. The directories mods-available and mods-enabled are used to control what optional software modules are set up to be used with the web servers.

Another important configuration on a system is the configuration of Secure SHell (/etc/ssh):

 2012 08 13 1046 Command Line Basics Part 2: Unix File System
The file ssh_config is controls how ssh works to connect from here to other systems. sshd_config (ssh daemon config) controls how ssh accepts connections from other systems.User's home directories are usually in the /home directory. So if my username is "me" then my home directory will be /home/me. (Side note: every unix-like system has a special user called "root" that has priviledges to do everything. root's home directory is a separate location, /root.Installed commands have their executable commands in directories like /bin (for normal commands) and /sbin (comands that the SuperUser, or root, use). Other directories used for those purposes are /usr/bin and /usr/sbin/. You mostly won't do anything in those directories (doing so could interfere with installed system software). If you create scripts or executable programs for everyone on your system to use, you can put them into /usr/local/bin. System package tools leave that directory alone, you can put stuff there and it won't be disturbed.

Modern Linux kernels have a window into the functioning of the kernel built into the file system, under the /proc directory. It's filled with virtual files that don't really exist on disk, but the contents of those files are populated by function calls to the kernel. The file /proc/cpuinfo, for instance, contains the kernel's information about the processor (the "more" command just prints the contents of a file to the command line display):

2012 08 13 1047 Command Line Basics Part 2: Unix File System

(I've only listed part of the output here). /proc/meminfo is useful too; it tells you information about virtual and physical RAM.

Finally, data for installed applications lives in the /var file system. The default location of the directory where the files for the apache web server live is /var/WWW. So to edit files on a new web server, you'd go to the /var/WWW and set up your files there.

So this is a very basic overview. Most of the files you'll need to get at as an admin will be in /etc or /var. Next time, I'll talk about options for editing files.

Craig Steffen cut his command-line teeth on MS-DOS 2.11 round about 1986 or 87; his first Unix-like OS was NeXT-Step on NeXT computers in 1991. He used Solaris, Irix, and increasingly Linux in graduate school, and runs mostly (Ubuntu) Linux nowadays. He lives in appalachia but oddly works for a mid-west University. In his spare time he mucks around with his vintage VW and occasionally flies small airplanes. You can see more at his blog and on twitter.

 

Are you a member of the Drupal Association?

2012 08 09 1420 Are you a member of the Drupal Association?

If you answer: yes, of course! I say thanks very much for supporting the best open source community ever! You should skip to the bottom to learn the ways you can help the Drupal project.

If you answer: what is this Association? I say:
The Drupal Association (DA) is a not-for-profit organization with the mission to help Drupal flourish. We help the Drupal community through a variety of programs and the benefits are seen in the Drupal project. Since Drupal is growing every day, the DA works to keep the growth sustainable by handling the day-to-day tasks that fall outside of working specifically on Drupal software. In fact, the DA has no authority over the planning, functionality, and development of the Drupal software because all of this is decided by the Drupal community.

Instead, the DA focuses on several key projects:

  • maintaining Drupal.org infrastructure and upgrades
  • empowering project contribution
  • providing Community Grants
  • hosting DrupalCons and funding DrupalCon Scholarships
  • organizing Global Training Days
  • legally protecting the Drupal project

There are many ways to get involved in the DA. Membership costs $30 (€22) year for Individuals or $100 (€73) year for Organizations. Your company can become a Supporting Partner or you could give time towards key projects to help make possible our strategic community initiatives.

Join Us Today! https://association.drupal.org

If you are ready to jump in and give time to help Drupal, there are many options:

  • search the issue queue for open issues that would benefit from your knowledge or opinions http://drupal.org/project/issues/
  • join your local Drupal User Group or a group that shares your interests on groups.drupal.org
  • check out the forums where people are asking and answering all kinds of questions drupal.org/forums
  • dig around on Drupal.org since there is a wealth of information there for you.

CMS Spotlight: PyroCMS

About the project
PyroCMS was started by Phil Sturgeon as an in-house CMS in 2008 and was released to logo CMS Spotlight: PyroCMSthe open source community in 2009. It soon picked up momentum and as I'm writing this it has received contributions from 100 different developers and designers and has been translated into 23 languages.

In 2011 we created 2 slightly different versions: Community and Professional. Community is free and always will be while Professional appeals to those of you who need features such as Multi-Site (create additional websites from the interface) and Rebranding (replace our logo and copyright information in the admin interface with your own). There is currently a team of 5 of us responsible for the project and business management:

  • Phil Sturgeon - Developer
  • Jerel Unruh - Developer
  • Adam Fairholm - Developer
  • Scott Parry - Designer
  • Mike Wilding – Support

Our Philosophy
The philosophy of the PyroCMS project is simple: a CMS doesn't have to do everything out of the box but everything it does should be intuitive to the user. You can quickly add additional functionality by installing or creating add-ons such as Modules (MVC packages), Widgets, Plugins, or Themes. PyroCMS is built from the ground up as a modular system and consequently extending it comes naturally for developers. Built with the MVC architecture it is used by many developers as a starting platform when creating custom applications.

Themes
Usually themes are the first thing you will encounter when working with a CMS. Creating a theme for PyroCMS couldn't get much easier. If you know HTML and CSS you are well on your way. A theme folder will typically contain the following items:

  • theme.php - This is a simple file that gives PyroCMS information such as the author's name
  • screenshot.png - A preview thumbnail to display in the theme switcher interface
  • img - A folder where all theme images are stored
  • js - A folder for all the necessary JavaScript
  • css - The folder for storing cascading stylesheets
  • views/layouts - The folder where you place your default.html template file
  • views/partials - Optionally break the default.html file into smaller chunks (such as header.html)

Not all of these items are required... you could create a theme with only theme.php and views/layouts/default.html!

Once you have the files in place you just inject the CMS output into your html file using the {{ template:body }} tag. Similarly you would use the {{ template:title }} and {{ template:metadata }} to let PyroCMS place the relevant meta data in your theme. That's it! You now have a working theme!

Modules
The PyroCMS core itself is built from modules: Pages, Blog, Files, etc are each a module. Modules are the only type of add-on that is accessible via the url. For example: site.com/your-module. Since modules are MVC packages you can create applications as simple or as complex as needed. They can collect data from users via forms, display all sorts of things, or even act as an API to communicate with other websites.

Widgets
Widgets are simple chunks of logic that you can embed anywhere. Suppose you wanted to embed a map on your site and have a non-technical user change the address once a week. This would be a good job for a widget. Widgets can be embedded anywhere on the front-end of your website using a tag that looks like this: {{ widgets:instance id="1" }} Once that is embedded the client can go to the Widgets interface in the admin panel and select that map widget. A form will open and they can edit the address details.

Plugins
Last but definitely not least let's talk about Plugins. Plugins are somewhat similar to Widgets except that they have no user interface. Plugins are intended for designers and others who want precise control over how data is output. They are called by embedding their tags in theme files or in Page content. Here is a quick example of using the File plugin to output a list of uploaded files:

{{ files:listing folder="our-vacation" }}
<img src="{{ url:site }}files/thumb/{{ id }}" alt="{{ description }}"/>
{{ /files:listing }}

The example will loop through all files in the "our-vacation" folder and for each one it will output an image tag.

Summary
Hopefully you've enjoyed this quick flyover of PyroCMS. We think you will like PyroCMS for the same reasons many others tell us they do:

  • Search engine friendly by default
  • An admin interface that users just "get" without training
  • A full featured free version with a paid version available if needed
  • Developer friendly due to its clear MVC and modular architecture
  • Installable on nearly any server supporting PHP 5.2 or greater and MySQL. (we have a hosted product too if you prefer)
  • Simple and concise tag system for outputting data

Drop by our site at PyroCMS.com for more information. You are also welcome to talk with @pyrocms or myself @jerelunruh anytime.

 CMS Spotlight: PyroCMSJerel Unruh started using PyroCMS v0.9.x in 2010 and soon began contributing to the project. He stuck around for the long haul and now heads up the US office and is credited with writing some very popular features in PyroCMS! When not wielding his web development tools he works with virtualization and server administration and spends his offline time on various automotive and mechanical projects.

Command Line Basics Part 1: moving around the file system

Previous post in this series available here.

One of the advantages of a command line over a graphical control system is that you have a very very rich set of commands to run, and very fine-grained control over how they're run. The dis-advantage is that you don't have "menu"s to choose commands from, so you need a base of knowledge before you can do anything. This post and the few after it are my attempt to give you a crash course on the vital basics of doing stuff on a (perhaps) virtual Linux machine with a remote command line login.

The first thing you'll do is "log in", or establish a connection to your virtual server. You'll use some sort of tool to do that, depending on the operating system of your local machine. If you already have a unix-like machine (including Linux), you'll probably open a command window and connect to the remote machine using the command "ssh" for "Secure SHell". If you're on a Windows machine, you'll use a program like "PuTTY". In either case, when you first get logged on you'll see a blast of general information from the machine and then a "prompt":

2012 07 03 1140 Command Line Basics Part 1: moving around the file system

The prompt is the thing at the bottom that is basically the remote machine saying "Ok, I'm ready for your next command". I've set up my prompt to tell me my username, what machine I'm logged into, what time it is, what directory I'm in ("~" in this case), then the "$" character indicates the end of the prompt and that's where the cursor sits, ready for you to type.

Directories in these machines are in a hierarchy. Unlike Windows (or DOS), the file system in a Unix-like machine isn't relative to a physical drive (like "C:"). Directories are mapped to underlying media, but in a way that's mostly invisible. All directories stem from a "root" directory that doesn't really have a name; it's just referred to as "/". The root directory of a file system will have 0 or more sub-directories, each of those will have 0 or more sub-directories, and so on down. Files can reside in any of these directories. Below briefly explain three important commands which tell you the current directory, change it to a different one, and see what's there.

Any time you have a prompt, you have some notion of your "current" directory. The command "pwd" (Print Working Directory) tells you which directory you're in. pwd is usually used without options.

The command "cd" (Change Directory) is used to change the current directory to a different one. It can be invoked several ways. "cd XXX" changes to a subdirectory of the current directory with the name XXX; this is a relative directory change; where you end up depends on where you are. "cd /XXX" changes to the directory /XXX/ no matter where you are (the leading slash makes it an "absolute" directory change).

There are a couple of useful other invocations of cd. "cd .." is a relative directory change, but instead of changing to a subdirectory of the current directory, it changes to the parent of the current directory (the name is not required since each directory is only the subdirectory of one parent). In other words, in general, running "cd XXX" then "cd .." puts you back where you started.

One other invocation of cd is "cd" with no arguments. That's a special case that is an absolute directory change that puts you back in your "home" directory. Every user on a unix-like system has a point in the file system where your own files are stored (as opposed to the files that make the system run or are part of the operating system). You store your own files there as well as files that will set up your environment (another post).

The third command, command "ls" (for "list", I guess) is used to list the names of the files and the subdirectories in the current directory. With no arguments, list just gives a complete listing of all the contents of a directory, including subdirectories and files together. (How to distinguish them will be a later post.)

Here's an illustration of me logging in and moving around in the directories on my virtual server. You'll notice that my prompt here tells you what the current directory is at each step, so using "pwd" is superfluous here. However, no matter what your prompt is, even if it gets messed up sometimes, pwd will always tell you where you are, so I've used it that way here. (Words that appear like this in the trascription aren't actually part of the session; they're notes to you, the reader.)

2012 07 03 1142 Command Line Basics Part 1: moving around the file system

This gives you a very basic idea of the mechanics of moving around the directory tree. The best way to try this is to log into your own server and see what's there. If you ever get confused about where you are, the command "cd" by itself will always return you to your home directory, and "cd /" will always return you to the root of the file system.

Next time, I'll talk about the file system layout in general and some of the useful places to go.

Craig Steffen cut his command-line teeth on MS-DOS 2.11 round about 1986 or 87; his first Unix-like OS was NeXT-Step on NeXT computers in 1991. He used Solaris, Irix, and increasingly Linux in graduate school, and runs mostly (Ubuntu) Linux nowadays. He lives in appalachia but oddly works for a mid-west University. In his spare time he mucks around with his vintage VW and occasionally flies small airplanes. You can see more at his blog and on twitter.

You think you know a lot about cPanel & WHM? Prove it with cPanel University.

logo You think you know a lot about cPanel & WHM? Prove it with cPanel University.cPanel University (cPU) is the brand new set of exams to test the technical and sales skills with cPanel & WHM. These are not your basic, participation ribbon certificates. cPanel University Professor Todd Thrash says, “The tests are brutal and passing means you possess functional, concrete knowledge of cPanel & WHM.” The tests are designed to be hard and boasts a passing rate of only 30%. cPanel offer two tracks, sales and technical, to concentrate focus on the different aspects of the product.

There are five phase levels of testing - Base, Professional, Expert, Veteran, and Master. When cPanel had two leading web hosting companies take the test, only two students passed 3 out of the 5 testing levels and went onto the fourth level - the Veteran Test. "With 5 years of experience with cPanel this test was a challenge to pass, although I only got to Expert I am confident with more focus and training I can get Master Certified," said Matthew Harris from  leading web host. “The test definitely touches base on Linux knowledge as well as advanced cPanel skills and is a good measure of who really knows cPanel."

Why should you get cPanel Certified?
I am glad you asked. You did ask, right? Of course you did. The cPanel Certifications are a benchmark of what the staff knows about the product. They prove how much cPanel & WHM skill a person has.

Who should get cPanel Certified?
Sales and Technical people should take the respective exams. Any company that wants to ensure their sales teams are not just being effective but maximizing the profitability of their cPanel offerings should ensure their sales teams are certified.

I want to take this awesome test, how do get in?
There is no need for an application or interview, head to university.cpanel.net and sign up now. There are five per track, one basic and four advanced. The basics are available 24/7/365 and are online.

When can take the advanced exams?
The advanced are only administered when cPanel University Proctors are on site at select venues. The two key events planned for 2012 are HostingCon and cPanel Conference.

Can’t get enough of the awesomeness that is cPanel University? Get over to univerisity.cpanel.net to check out the test and learn more!

Travis Ellis is a Marketing Associate at cPanel, Inc. Travis creates content, works with event planning, and contains a unique blend of SysAdmin and Communications Nerd. This allows him to go from command line to entertaining guests in no time flat. Travis is the Marketing Contact for cPanel University and works with the cPU team. 

Join us for our Webinar with Standing Cloud

We're excited to be able to announce that we'll be holding our first webinar next week to show off our new Hosted Apps product. Even better, we're able to do the webinar together with our friends at Standing Cloud.

The webinar, titled "Ease the Burden of Application Deployment: Hosted Apps on VPS.NET and Standing Cloud", will show you many of the ways you can make deploying applications an absolute breeze. We've scheduled two times for the webinar; the first, Wednesday, May 30th at 10 AM EDT (GMT -5) and the second, Wednesday, June 6th at 12 PM EDT. You're able to register for the webinars at http://www.standingcloud.com/webinar-signup

By using the Hosted Apps at VPS.NET, you're able to easily deploy applications in just a few minutes. Not only does this make the deployment of applications easier and faster, but they also continue to save you time in the long run, as the applications are automatically updated.

Standing Cloud, which provides the software making it possible to do the turnkey application deployment, has an extravagant and thorough application marketplace. Once inside the market place, you're able to choose from over 100 different applications, made to solve a wide variety of problems. Some of the most commonly deployed applications include Drupal, MoveableType & WordPress. There are many other applications available in the Standing Cloud market place, aimed at making life easier for the small businesses out there.

  • OpenHRM - A popular human resources management tool, which includes an employee self service module.
  • Magento - A full featured eCommerce software, that allows you to be able to setup an online business in just a few minutes.
  • OpenX - An ad server solution that allows website owners the capability to easily sell advertising opportunities on their site.
  • SugarCRM - A customer relations management tool, making sales and marketing campaigns much easier to organize and track the success rates of.

All of these applications and many more can be automatically installed using the VPS.NET Hosted Apps option. You're able to strategically place your server closest to you or your customers, choosing between either a US or UK VPS.NET Cloud Server.

We're really excited about this webinar, and we happy to be able to show you several different ways the Hosted Apps can make your life easier. Registration and attendance of the webinar is totally free.

We hope to see you there!