Recently I received a very interesting comment about the use of Open Source software – the commenter stated he thought that Open Source software created a society of more democracy, more openness and less concentration of power and for him economic benefit is not so important as democracy.
This posed an interesting question for me; does the Open Source software enhance democracy or stimulate the economy? I came up with an answer of “Yes, but it depends…” The concept of open source is going to become an undercurrent to almost everything the new United States administration does," declared Open Source Initiative (OSI)'s Michael Tiemann. "The American concept of democracy is not just of the people and by the people but with the people." He said we have already seen a commitment to this open philosophy throughout President Obama's election campaign. Mr. Tiemann went on to say, "I think what we will see now is a maturation in America and around the world of an understanding of the open source model."
When pondering this question, I found myself on the horns of a dilemma. I realized that this was not a binary question. If I am in a dictatorship, it may make no difference how much software I write and distribute freely under a GNU license, I still am in a dictatorial regime and thus in this case, the answer is No! However if I am fortunate enough to live in a country whose overnmental foundation is democratic, the production and Open Source distribution of software available to the general populace does enhance democracy by empowering more people than commercial proprietary software – the last United States Presidential election is a case in point – Yes, Open Source software does enhance democracy. The ready availability (meaning free or inexpensive) of various types of modifiable applications to the general public confirmed a genre whereby individual citizens could express their opinions and amuse or annoy the rest of the citizenry.
Now as far as being an economic stimulus – the conventional answer is: Yes, but Open Source software comes with an explicit or implicit price tag. If as a small business or a government agency, you do not understand this, you are in for a rude surprise. It should not come as a mystery why companies that were producers of large and expensive proprietary software are now co-opting Open Source software companies or adopting a previously unimaginable Open Source philosophy.
Potential Open Source clients need to be aware that, just like democracy, it comes with a price – diligence. If your choice of an OS application is not mature, you may find you’re with unexpected development costs and at lease Operations & Maintenance (O&M) costs.
On the up side, I have found that through diligent research, Open Source software can serve as a catalytic framework (at a minimum) or as a complete application (requiring on configuration) – depending on you requirements.
OK, so what do you think….?
Monday, January 26, 2009
Monday, January 12, 2009
Common Mistakes made by new LINUX Administrators
MAI in our quest to enlighten, share and empower are always seeking knowledge worthy of sharing. This Blog Article takes advantage of the knowledge of Jack Wallen:
A major player and writer of Linux articles for TechRepublic. Jack was responsible for bringing Linux to TechRepublic. And for years Jack not only managed the Linux content on the site but was the primary writer for that OS that most thought only fit for schools and hacker basements. Time did march on and so did the acceptance of Linux. Jack keeps his Linux fingers typing to help others learn the ins and outs of the OS. In his "spare" time, Jack does graphic/web designs, writes crime-thrillers (waiting to be published), and mountain bikes with his lovely wife.
For many, migrating to Linux is a rite of passage that equates to a thing of joy. For others, it’s a nightmare waiting to happen. It’s wonderful when it’s the former; it’s a real show stopper when it’s the latter. But that nightmare doesn’t have to happen, especially when you know, first hand, the most common mistakes new Linux administrators make. This article will help you avoid those mistakes by laying out the most typical Linux missteps.
Note: This information is also available as a PDF download.
#1: Installing applications from various types
This might not seem like such a bad idea at first. You are running Ubuntu so you know the package management system uses .deb packages. But there are a number of applications that you find only in source form. No big deal right? They install, they work. Why shouldn’t you? Simple, your package management system can’t keep track of what you have installed if it’s installed from source. So what happens when package A (that you installed from source) depends upon package B (that was installed from a .deb binary) and package B is upgraded from the update manager? Package A might still work or it might not. But if both package A and B are installed from .debs, the chances of them both working are far higher. Also, updating packages is much easier when all packages are from the same binary type.
#2: Neglecting updates
Okay, this one doesn’t point out Linux as much as it does poor administration skills. But many admins get Linux up and running and think they have to do nothing more. It’s solid, it’s secure, it works. Well, new updates can patch new exploits. Keeping up with your updates can make the difference between a compromised system and a secure one. And just because you can rest on the security of Linux doesn’t mean you should. For security, for new features, for stability — the same reasons we have all grown accustomed to updating with Windows — you should always keep up with your Linux updates.
#3: Poor root password choice
Okay, repeat after me: “The root password is the key to the kingdom.” So why would you make the key to the kingdom simple to crack? Sure, make your standard user password something you can easily remember and/or type. But that root password — you know, the one that’s protecting your enterprise database server — give that a much higher difficulty level. Make that password one you might have to store, encrypted, on a USB key, requiring you to slide that USB key into the machine, mount it, decrypt the password, and use it.
#4: Avoiding the command line
No one wants to have to memorize a bunch of commands. And for the most part, the GUI takes care of a vast majority of them. But there are times when the command line is easier, faster, more secure, and more reliable. Avoiding the command line should be considered a cardinal sin of Linux administration. You should at least have a solid understanding of how the command line works and a small arsenal of commands you can use without having to RTFM. With a small selection of command-line tools on top of the GUI tools, you should be ready for just about anything.
For More information on these items and other mistakes new LINUX administrators make; See TechRepublic article at http://blogs.techrepublic.com.com/10things/?p=455
#5: Not keeping a working kernel installed
Let’s face it, you don’t need 12 kernels installed on one machine. But you do need to update your kernel, and the update process doesn’t delete previous kernels. What do you do? You keep at least the most recently working kernel at all times. Let’s say you have 2.6.22 as your current working kernel and 2.6.20 as your backup. If you update to 2.6.26 and all is working well, you can remove 2.6.20. If you use an rpm-based system, you can use this method to remove the old kernels: rpm -qa grep -i kernel followed by rpm-e kernel-{VERSION}.
#6: Not backing up critical configuration files
How many times have you upgraded X11 only to find the new version fubar’d your xorg.conf file to the point where you can no longer use X? It used to happen to me a lot when I was new to Linux. But now, anytime X is going to be updated I always back up /etc/X11/xorg.conf in case the upgrade goes bad. Sure, an X update tries to back up xorg.conf, but it does so within the /etc/X11 directory. And even though this often works seamlessly, you are better off keeping that backup under your own control. I always back up xorg.conf to the /root directory so I know only the root user can even access it. Better safe than sorry. This applies to other critical backups, such as Samba, Apache, and MySQL, too.
#7: Booting a server to X
When a machine is a dedicated server, you might want to have X installed so some administration tasks are easier. But this doesn’t mean you should have that server boot to X. This will waste precious memory and CPU cycles. Instead, stop the boot process at runlevel 3 so you are left at the command line. Not only will this leave all of your resources to the servers, it will also keep prying eyes out of your machine (unless they know the command line and passwords to log in). To log into X, you will simply have to log in and run the command startx to bring up your desktop.
#8: Not understanding permissions
Permissions can make your life really easy, but if done poorly, can make life really easy for hackers. The simplest way to handle permissions is using the rwx method. Here’s what they mean: r=read, w=write, x=execute. Say you want a user to be able to read a file but not write to a file. To do this, you would issue chmod u+r,u-wx filename. What often happens is that a new user sees an error saying they do not have permission to use a file, so they hit the file with something akin to chmod 777 filename to avoid the problem. But this can actually cause more problems because it gives the file executable privileges. Remember this: 777 gives a file rwx permissions to all users (root, group, and other), 666 gives the file rw privileges to all users, 555 gives the file rx permissions to all users, 444 gives r privileges to all users, 333 gives wx privileges to all users, 222 gives w privileges to all users, 111 gives x privileges to all users, and 000 gives no privileges to all users.
#9: Logging in as root user
I can’t stress this enough. Do NOT log in as root. If root privilege access is needed to execute or configure an application, you should su to root in a standard user account. Why is logging in as root bad? Well, when you log on as a standard user, all running X applications still have access only to the system limited to that user. If you log in as root, X has all root permissions. This can cause two problems: 1) if you make a big mistake via a GUI, that mistake can be catastrophic to the system and 2) with X running as root that makes your system more vulnerable.
#10: Ignoring log files
There is a reason /var/log exists. It is a single location for all log files. This makes it simple to remember where you first need to look when there is a problem. Possible security issue? Check /var/log/secure. One of the very first places I look is /var/log/messages. This log file is the common log file where all generic errors and such are logged to. In this file you will get messages about networking, media changes, etc. When administering a machine you can always use a third-party application such as logwatch that can create various reports for you based on your /var/log files.
Sidestep the problems
These 10 mistakes are pretty common among new Linux administrators. Avoiding the pitfalls will take you through the Linux migration rite of passage faster, and you will come out on the other side a much better administrator.
A major player and writer of Linux articles for TechRepublic. Jack was responsible for bringing Linux to TechRepublic. And for years Jack not only managed the Linux content on the site but was the primary writer for that OS that most thought only fit for schools and hacker basements. Time did march on and so did the acceptance of Linux. Jack keeps his Linux fingers typing to help others learn the ins and outs of the OS. In his "spare" time, Jack does graphic/web designs, writes crime-thrillers (waiting to be published), and mountain bikes with his lovely wife.For many, migrating to Linux is a rite of passage that equates to a thing of joy. For others, it’s a nightmare waiting to happen. It’s wonderful when it’s the former; it’s a real show stopper when it’s the latter. But that nightmare doesn’t have to happen, especially when you know, first hand, the most common mistakes new Linux administrators make. This article will help you avoid those mistakes by laying out the most typical Linux missteps.
Note: This information is also available as a PDF download.
#1: Installing applications from various types
This might not seem like such a bad idea at first. You are running Ubuntu so you know the package management system uses .deb packages. But there are a number of applications that you find only in source form. No big deal right? They install, they work. Why shouldn’t you? Simple, your package management system can’t keep track of what you have installed if it’s installed from source. So what happens when package A (that you installed from source) depends upon package B (that was installed from a .deb binary) and package B is upgraded from the update manager? Package A might still work or it might not. But if both package A and B are installed from .debs, the chances of them both working are far higher. Also, updating packages is much easier when all packages are from the same binary type.
#2: Neglecting updates
Okay, this one doesn’t point out Linux as much as it does poor administration skills. But many admins get Linux up and running and think they have to do nothing more. It’s solid, it’s secure, it works. Well, new updates can patch new exploits. Keeping up with your updates can make the difference between a compromised system and a secure one. And just because you can rest on the security of Linux doesn’t mean you should. For security, for new features, for stability — the same reasons we have all grown accustomed to updating with Windows — you should always keep up with your Linux updates.
#3: Poor root password choice
Okay, repeat after me: “The root password is the key to the kingdom.” So why would you make the key to the kingdom simple to crack? Sure, make your standard user password something you can easily remember and/or type. But that root password — you know, the one that’s protecting your enterprise database server — give that a much higher difficulty level. Make that password one you might have to store, encrypted, on a USB key, requiring you to slide that USB key into the machine, mount it, decrypt the password, and use it.
#4: Avoiding the command line
No one wants to have to memorize a bunch of commands. And for the most part, the GUI takes care of a vast majority of them. But there are times when the command line is easier, faster, more secure, and more reliable. Avoiding the command line should be considered a cardinal sin of Linux administration. You should at least have a solid understanding of how the command line works and a small arsenal of commands you can use without having to RTFM. With a small selection of command-line tools on top of the GUI tools, you should be ready for just about anything.
For More information on these items and other mistakes new LINUX administrators make; See TechRepublic article at http://blogs.techrepublic.com.com/10things/?p=455
#5: Not keeping a working kernel installed
Let’s face it, you don’t need 12 kernels installed on one machine. But you do need to update your kernel, and the update process doesn’t delete previous kernels. What do you do? You keep at least the most recently working kernel at all times. Let’s say you have 2.6.22 as your current working kernel and 2.6.20 as your backup. If you update to 2.6.26 and all is working well, you can remove 2.6.20. If you use an rpm-based system, you can use this method to remove the old kernels: rpm -qa grep -i kernel followed by rpm-e kernel-{VERSION}.
#6: Not backing up critical configuration files
How many times have you upgraded X11 only to find the new version fubar’d your xorg.conf file to the point where you can no longer use X? It used to happen to me a lot when I was new to Linux. But now, anytime X is going to be updated I always back up /etc/X11/xorg.conf in case the upgrade goes bad. Sure, an X update tries to back up xorg.conf, but it does so within the /etc/X11 directory. And even though this often works seamlessly, you are better off keeping that backup under your own control. I always back up xorg.conf to the /root directory so I know only the root user can even access it. Better safe than sorry. This applies to other critical backups, such as Samba, Apache, and MySQL, too.
#7: Booting a server to X
When a machine is a dedicated server, you might want to have X installed so some administration tasks are easier. But this doesn’t mean you should have that server boot to X. This will waste precious memory and CPU cycles. Instead, stop the boot process at runlevel 3 so you are left at the command line. Not only will this leave all of your resources to the servers, it will also keep prying eyes out of your machine (unless they know the command line and passwords to log in). To log into X, you will simply have to log in and run the command startx to bring up your desktop.
#8: Not understanding permissions
Permissions can make your life really easy, but if done poorly, can make life really easy for hackers. The simplest way to handle permissions is using the rwx method. Here’s what they mean: r=read, w=write, x=execute. Say you want a user to be able to read a file but not write to a file. To do this, you would issue chmod u+r,u-wx filename. What often happens is that a new user sees an error saying they do not have permission to use a file, so they hit the file with something akin to chmod 777 filename to avoid the problem. But this can actually cause more problems because it gives the file executable privileges. Remember this: 777 gives a file rwx permissions to all users (root, group, and other), 666 gives the file rw privileges to all users, 555 gives the file rx permissions to all users, 444 gives r privileges to all users, 333 gives wx privileges to all users, 222 gives w privileges to all users, 111 gives x privileges to all users, and 000 gives no privileges to all users.
#9: Logging in as root user
I can’t stress this enough. Do NOT log in as root. If root privilege access is needed to execute or configure an application, you should su to root in a standard user account. Why is logging in as root bad? Well, when you log on as a standard user, all running X applications still have access only to the system limited to that user. If you log in as root, X has all root permissions. This can cause two problems: 1) if you make a big mistake via a GUI, that mistake can be catastrophic to the system and 2) with X running as root that makes your system more vulnerable.
#10: Ignoring log files
There is a reason /var/log exists. It is a single location for all log files. This makes it simple to remember where you first need to look when there is a problem. Possible security issue? Check /var/log/secure. One of the very first places I look is /var/log/messages. This log file is the common log file where all generic errors and such are logged to. In this file you will get messages about networking, media changes, etc. When administering a machine you can always use a third-party application such as logwatch that can create various reports for you based on your /var/log files.
Sidestep the problems
These 10 mistakes are pretty common among new Linux administrators. Avoiding the pitfalls will take you through the Linux migration rite of passage faster, and you will come out on the other side a much better administrator.
Subscribe to:
Posts (Atom)