In early 2007 I began playing around with the idea of doing everything from the command-line. Not command-line in GNOME mind you, but command-line without X running at all. I switched my computer into init 3 for at least a week, and I was able to do tasks like coding, chatting on MSN messenger, IRC, browsing Wikipedia, watch videos and play audio files all from the terminal without having a graphical session at all. You might be wondering how you can do all of these in a world of only text, but I did it.
Web browsing was the biggest priority for me, and as a result I found a few basic web browsers you could use. They do not load graphical images in themselves so all you do is read text, and page layout is significantly different on some sites. The main program I used is called elinks. It is very simple to use, and pretty straight forward.
For chatting with friends I was able to use a program called centerim. It supports multiple chat protocols such as ICQ, Yahoo!, MSN, AIM, IRC, Gadu-Gadu, and Jabber (which means Google Talk is supported with a little work). At the time I only used MSN and IRC, and for IRC I used another program called irssi instead.
The coolest part was being able to watch videos. The program you use for this is good old mplayer. These days it takes tweaking to get it working in proper order, and I am still trying to figure out how to get audio working on videos under root. When I did it, I was using Fedora Core 6, and all I needed to do was become root, and I had color videos rendered just as well as if not better than on the graphical desktop. I think the reason it doesn't work now is I need to tweak a few things to have root interact with pulseaudio. Mplayer worked much the same way for playing mp3s and other audio files that you would use.
You might wonder what are the advantages to doing things this way. Number one you will save tons on memory and CPU cycles if those are important to you. I could probably slim my memory profile down to less than 256 MB on boot in init 3. The other thing is how cool it looks when all you have is black and white text which only you know how to operate with all the commands unknown to most everyone else. If you have questions about how to get other tasks done on the command-line feel free to leave a question in the comments area.
Sunday, February 27, 2011
Wednesday, February 9, 2011
FreeBSD: I got it working finally.
I want to apologize for straying off on to philosophical and personal tangents with this blog. Part of an apologize is repentance. With that I have a slight review of FreeBSD and a little bit about how to make it user friendly after initial install.
About five years ago was the first time I heard about FreeBSD. I was a new Linux user, and I was soaking up all the information I could about Linux and Unix. FreeBSD is a continuation of the code base for BSD Unix which became popular in the 1970s and 80s with several universities and companies. Its demise in popularity came about from the Unix related lawsuits of the late 80s and early 90s. In the early 90s the code base was ported to the 386 processor (the first 32-bit chip for personal computers) and FreeBSD was born. It's kernel is a micro kernel where different services such as internet protocol are plugged in as a server to the kernel rather than apart of the kernel itself like a monolithic kernel like Linux. For determining which is a better design you can do some digging and use Google because I have no opinion.
After I heard about FreeBSD I downloaded it and wanted to give it a shot. The downside was it didn't want to easily coexist with my Linux partitions so I left it alone for the next four years. After virtual machines became popular I started playing around with it in Qemu which comes default on Fedora, but it refused to work so I left it alone another year.
After I went home this break, my uncle introduced me to VMWare Player. This is free from VMWare, and it supports several operating systems. Considering my role as a network administrator it is a very useful tool. I have lately been working on making a virtual machine to function as a backup for basic operations when our server goes down at school. If the server goes down, I just leave my laptop in a convenient spot and boot up the virtual machine. I can then work on bringing the system back up without twenty people telling me the internet is down.
I decided to give FreeBSD a shot once more. This time we had success. I used most of the default options and tried to install most things I thought I would use or tinker with at least. Everything worked, but it only left me with a command-line. No problem for me seeing I love using the command-line. At the same time though I want the graphical portion to work also. This is what took some work to get setup. The first thing you need to do is install Gnome and GDM. Gnome is the default environment for Fedora, Ubuntu, and Debian among others. It normally has a menu at the top left of the screen, a clock in the top right, and task bar on the bottom. GDM is where you login at once the system has started. For GDM to start on startup I had to manually edit the /etc/rc.conf and add the line gdm_enable="YES". After that no users popped into the users box. With a little digging I found out I needed to add procfs to fstab. After that graphical was all working.
Updates are painfully slow. They have many advantages such as saving space by compiling support for only what you need or making it as versatile as you want. Compiling several updates took me a whole week on and off and letting my computer run. Part of the delay involved the need for checking which options I wanted compiled on every package in the segments of the process rather than it all being up front.
My recommendation is FreeBSD is not for the faint in heart. This is something for the advanced user to tinker with or someone with a great deal of patience. If you want to play around with it there is plenty of documentation for it. I may do more with it; I may not.
About five years ago was the first time I heard about FreeBSD. I was a new Linux user, and I was soaking up all the information I could about Linux and Unix. FreeBSD is a continuation of the code base for BSD Unix which became popular in the 1970s and 80s with several universities and companies. Its demise in popularity came about from the Unix related lawsuits of the late 80s and early 90s. In the early 90s the code base was ported to the 386 processor (the first 32-bit chip for personal computers) and FreeBSD was born. It's kernel is a micro kernel where different services such as internet protocol are plugged in as a server to the kernel rather than apart of the kernel itself like a monolithic kernel like Linux. For determining which is a better design you can do some digging and use Google because I have no opinion.
After I heard about FreeBSD I downloaded it and wanted to give it a shot. The downside was it didn't want to easily coexist with my Linux partitions so I left it alone for the next four years. After virtual machines became popular I started playing around with it in Qemu which comes default on Fedora, but it refused to work so I left it alone another year.
After I went home this break, my uncle introduced me to VMWare Player. This is free from VMWare, and it supports several operating systems. Considering my role as a network administrator it is a very useful tool. I have lately been working on making a virtual machine to function as a backup for basic operations when our server goes down at school. If the server goes down, I just leave my laptop in a convenient spot and boot up the virtual machine. I can then work on bringing the system back up without twenty people telling me the internet is down.
I decided to give FreeBSD a shot once more. This time we had success. I used most of the default options and tried to install most things I thought I would use or tinker with at least. Everything worked, but it only left me with a command-line. No problem for me seeing I love using the command-line. At the same time though I want the graphical portion to work also. This is what took some work to get setup. The first thing you need to do is install Gnome and GDM. Gnome is the default environment for Fedora, Ubuntu, and Debian among others. It normally has a menu at the top left of the screen, a clock in the top right, and task bar on the bottom. GDM is where you login at once the system has started. For GDM to start on startup I had to manually edit the /etc/rc.conf and add the line gdm_enable="YES". After that no users popped into the users box. With a little digging I found out I needed to add procfs to fstab. After that graphical was all working.
Updates are painfully slow. They have many advantages such as saving space by compiling support for only what you need or making it as versatile as you want. Compiling several updates took me a whole week on and off and letting my computer run. Part of the delay involved the need for checking which options I wanted compiled on every package in the segments of the process rather than it all being up front.
My recommendation is FreeBSD is not for the faint in heart. This is something for the advanced user to tinker with or someone with a great deal of patience. If you want to play around with it there is plenty of documentation for it. I may do more with it; I may not.
Monday, February 7, 2011
The Howto on Being And Making Linux Users
When I first became a Linux user, I wondered how will I master all of this information. Can I actually use this operating system for everything? Obviously the answer to that question now is yes. Everyone goes through this period when they begin migrating to Linux. The process for becoming a Linux user is the same one you want to put others through to make them Linux users. Your goal is to become an independent user. What do I mean by that. You need to be able to fix your own problems. You need to be able to set up your own printer, wireless drivers, and make whatever other tweaks you make.
At first you are always confronted with problems. The internet doesn't work. The display manager isn't behaving like it does for your friend. Wine refuses to run that program I need so badly. You need to quit viewing these things as problems, but instead as learning opportunities. These problems give you a chance to become acquainted different components in Linux. Internet not working gives you a chance to better understand your network devices and wherever the problem is at. Gnome misbehaving has the advantage of you're not only fixing it, but also of a knowledge of how to customize it to your liking. As for wine I am still looking for advantages to working with problems on that, but have not found any yet. Remember these are learning opportunities for your own good.
The next thing to remember is not to have your Linux savvy friend do everything for you. This is bypassing the whole independent process. Your friend already knows how to fix things and this just extends his knowledge a little bit compared to you learning a lot from a simple problem. This is how you eventually give up on using Linux because supporting yourself is a requirement of using it. Your Linux savvy friend will not always be with you. When a problem arises, try to fix it yourself first and avoid going to your friend until you have run out of options, and I do mean run out of options.
Make Google your friend. You would be surprised how much I use Google to get help from the online community. You might wonder how is that different from asking help from your friend. It's different in that you have to learn how to use some of the things suggested as fixes unless you use a script someone else wrote. In learning different commands you figure out how to navigate the command line, use man pages, edit configuration files, etc. You do these things yourself, and you figure out how to use your system to its full potential. The Linux community knows how to help people by teaching them.
Now to the making users portion. Never ever let your new user be lazy. Get them thinking about how to solve the problem. If they want your help, do not run over and go fix the problem. Give them advice they can implement and let them do it. The only time you want to help them is if they just installed and they are having a multitude of problems and are not committed to using this thing at all. If they are committed, only teach them. Do not do for them. Sometimes they will get impatient. In moments like these lift your finger only a little bit, and it satisfies them. Do not go to far to help them as it only acclimates them to being lazy again. The best thing you can do to help them is get them to help themselves. The idea that giving a man a fish helps him eat for a day, but teaching that man to fish enables him to eat for a lifetime. The same holds true for Linux.
The advantages to this approach last. One friend of mine is naturally independent and when we got Linux working on his computer, he took off with it asking for my help only when it was absolutely essential. He has since taught others and made Linux users out of more people. Another friend of mine was working with me in a canvassing program, and I peaked his curiosity. We attempted to install Fedora on his machine before the program was over and failed. We parted company, and unbeknown to be he still tried to get it working and did. He had more questions about how to get this and that working to which I was hesitant to answer as that is part of the process. Needless to say he got impatient and fixed it himself. He is now using Linux solidly and has converted others to using it too. The approach works with those who are committed, but those who are not fall by the way side. For those it does work with, they become a help rather than ones who need help. They even help you with fixing your problems.
This is the process. The goal is independence, and when this is achieved, your work has been accomplished. You are now a true Linux user, and whoever you work with will be also.
At first you are always confronted with problems. The internet doesn't work. The display manager isn't behaving like it does for your friend. Wine refuses to run that program I need so badly. You need to quit viewing these things as problems, but instead as learning opportunities. These problems give you a chance to become acquainted different components in Linux. Internet not working gives you a chance to better understand your network devices and wherever the problem is at. Gnome misbehaving has the advantage of you're not only fixing it, but also of a knowledge of how to customize it to your liking. As for wine I am still looking for advantages to working with problems on that, but have not found any yet. Remember these are learning opportunities for your own good.
The next thing to remember is not to have your Linux savvy friend do everything for you. This is bypassing the whole independent process. Your friend already knows how to fix things and this just extends his knowledge a little bit compared to you learning a lot from a simple problem. This is how you eventually give up on using Linux because supporting yourself is a requirement of using it. Your Linux savvy friend will not always be with you. When a problem arises, try to fix it yourself first and avoid going to your friend until you have run out of options, and I do mean run out of options.
Make Google your friend. You would be surprised how much I use Google to get help from the online community. You might wonder how is that different from asking help from your friend. It's different in that you have to learn how to use some of the things suggested as fixes unless you use a script someone else wrote. In learning different commands you figure out how to navigate the command line, use man pages, edit configuration files, etc. You do these things yourself, and you figure out how to use your system to its full potential. The Linux community knows how to help people by teaching them.
Now to the making users portion. Never ever let your new user be lazy. Get them thinking about how to solve the problem. If they want your help, do not run over and go fix the problem. Give them advice they can implement and let them do it. The only time you want to help them is if they just installed and they are having a multitude of problems and are not committed to using this thing at all. If they are committed, only teach them. Do not do for them. Sometimes they will get impatient. In moments like these lift your finger only a little bit, and it satisfies them. Do not go to far to help them as it only acclimates them to being lazy again. The best thing you can do to help them is get them to help themselves. The idea that giving a man a fish helps him eat for a day, but teaching that man to fish enables him to eat for a lifetime. The same holds true for Linux.
The advantages to this approach last. One friend of mine is naturally independent and when we got Linux working on his computer, he took off with it asking for my help only when it was absolutely essential. He has since taught others and made Linux users out of more people. Another friend of mine was working with me in a canvassing program, and I peaked his curiosity. We attempted to install Fedora on his machine before the program was over and failed. We parted company, and unbeknown to be he still tried to get it working and did. He had more questions about how to get this and that working to which I was hesitant to answer as that is part of the process. Needless to say he got impatient and fixed it himself. He is now using Linux solidly and has converted others to using it too. The approach works with those who are committed, but those who are not fall by the way side. For those it does work with, they become a help rather than ones who need help. They even help you with fixing your problems.
This is the process. The goal is independence, and when this is achieved, your work has been accomplished. You are now a true Linux user, and whoever you work with will be also.
Tuesday, February 1, 2011
Applications: Where are they?!
When I first started using Linux, it was late 2005. The distro was the hailed Fedora Core 4. I was thrilled with the prospect of actually using this operating system I heard so much about. In the packages section I checked off all the interesting applications and utilities I wanted installed. One of them was gcc and g++. Much to my surprise after everything installed it wasn't in my applications menu. You may know where I am coming from. What you need to understand is that there are two different types of user interfaces. One is a graphical user interface which we will call a gui from here on; the other is the command-line interface which we will just call CLI from here on.
CLI and the GUI are fundamentally different. The GUI is driven by the invention of the mouse and its involvement in the user experience. This is what powers your word processor, internet browser (if you are not on the command-line using elinks or lynx right now), movie player, etc. If you don't understand what a GUI is, chances are you are using it or you are an Unix user who just woke up from 1983 who somehow knows what the internet is without encountering a GUI yet. All of your day to day applications are GUI driven.
CLI is a very simple but powerful interface. If you ever saw a DOS prompt or Linux terminal, this is a CLI. This is officially the true hackers, crackers, and script kiddies playground. Hackers and crackers enjoy it the most, but it isn't only for them. Command-line has lots of useful tools for obtaining information on the system such as networking, CPU architecture, processes, file systems, etc. Most Linux/Unix utilities are written for the command-line only. gcc and g++ are two examples of command-line only programs. The reason I didn't see these in the applications menu is they are designed to be used from the terminal.
After I made this discovery I quickly found out how to use gcc and g++. It took me a little longer to learn how to execute the executables they produced, but everything worked out eventually. The best thing you can do to learn this environment is use google and the man and apropos commands. To find the different programs you may want to use look in the /bin, /usr/bin, /usr/sbin, and /sbin folders. Then to find out more about that specific command type in man command. Another great place is the Linux Documentation Project (www.tldp.org).
Using the command-line will seem weird at first, but it is very rewarding. I can find my IP address for any given device with only one command in comparison to three or four mouse clicks in Windows. I can kill an offending process with only one command and 3 sequences of keystrokes. I can do updates with only one command. Bottom line it is far more efficient to use, and if I want to save myself from using a series of commands repeatedly I can always write a shell script to streamline the process.
CLI and the GUI are fundamentally different. The GUI is driven by the invention of the mouse and its involvement in the user experience. This is what powers your word processor, internet browser (if you are not on the command-line using elinks or lynx right now), movie player, etc. If you don't understand what a GUI is, chances are you are using it or you are an Unix user who just woke up from 1983 who somehow knows what the internet is without encountering a GUI yet. All of your day to day applications are GUI driven.
CLI is a very simple but powerful interface. If you ever saw a DOS prompt or Linux terminal, this is a CLI. This is officially the true hackers, crackers, and script kiddies playground. Hackers and crackers enjoy it the most, but it isn't only for them. Command-line has lots of useful tools for obtaining information on the system such as networking, CPU architecture, processes, file systems, etc. Most Linux/Unix utilities are written for the command-line only. gcc and g++ are two examples of command-line only programs. The reason I didn't see these in the applications menu is they are designed to be used from the terminal.
After I made this discovery I quickly found out how to use gcc and g++. It took me a little longer to learn how to execute the executables they produced, but everything worked out eventually. The best thing you can do to learn this environment is use google and the man and apropos commands. To find the different programs you may want to use look in the /bin, /usr/bin, /usr/sbin, and /sbin folders. Then to find out more about that specific command type in man command. Another great place is the Linux Documentation Project (www.tldp.org).
Using the command-line will seem weird at first, but it is very rewarding. I can find my IP address for any given device with only one command in comparison to three or four mouse clicks in Windows. I can kill an offending process with only one command and 3 sequences of keystrokes. I can do updates with only one command. Bottom line it is far more efficient to use, and if I want to save myself from using a series of commands repeatedly I can always write a shell script to streamline the process.
Tuesday, January 18, 2011
Many Distributions but Little Time
Chances are if you have looked at this blog you are interested in Linux or you know me personally. One of the major hurdles when someone wants to try out Linux is which one. I am hoping to give a slight overview of the features and benefits of each, so you can make the choice that fits you best.
Out of the popular distros the least user friendly are Slackware, Gentoo, Arch, Linux from Scratch (it's not really a distro, but a howto on putting a Linux system together from scratch) and probably a few others I can throw in the list. These three will guide you through what to do, but it is a lot of work to do it. It can be overwhelming for a beginner or even an advanced user like myself. I have never used Slackware, but I have tried. Gentoo I got running, and recently I tried to install it in a virtual machine, and the list of instructions was way to long and involved for someone with the amount of time I have. Arch was probably the easiest of the bunch, but it involves using the command line quite a bit. If you are up for a challenge, these would be the distributions to use. By the end you will know quite a bit about how Linux works.
We then have our server category. Normally for a server you do not want the latest, greatest, and fastest update cycle in the world. This means you will want to use something a little older with a little more trial than the average distro. Some distributions you would want to look at are Red Hat Enterprise Linux, Oracle Enterprise Linux, Debian, CentOS, and OpenSuSe. There are a few others I could mention, but these are probably the most stable as in few bugs. Red Hat, Oracle, and CentOS are all related to each other because Oracle and CentOS are derived from Red Hat. Debian stands on its own. OpenSuSe I know less about, and that is for a reason. I am not a fan of OpenSuSe because its package manager is slow and buggy, and the operating system reflects this fact in other areas. Red Hat you will have to pay a contract for updates and support, Oracle you will have to pay a contract for support, and CentOS you are your support. Debian is pretty respectable too, but Red Hat is the creme of the crop as far I am concerned. If you are on a limited budget, CentOS is the best way to go.
For a desktop system some of our other choices would be OpenSuSe, Fedora, Ubuntu, Debian, Mandrivia, and countless others. I am of the same opinion still on OpenSuse. Fedora is the latest, greatest, and fastest update cycle you can get. It is so fast, they call it the bleeding edge, and bleeding for a reason. There have been a few times where the bugs have been too much, and they get worked out within about a month of Fedora having a release most of the time. Sometimes it takes two or three months to get some of the bugs that bother you out. Otherwise it is a great desktop and it has been my primary distribution for the majority of my Linux experience with the exception of a semester. Ubuntu is based on Debian with a bit of a faster release cycle, but it is slower on updates than Fedora. Ubuntu makes heavy use of sudo which I think is fundamentally unsecure, but I will write more on that later. Ubuntu has a richer collection of software thanks to the fact it is based on Debian. Debian has a large software repository. Most open source projects will have a package somewhere in the Debian repository. I would vote using the Debian testing branch over Ubuntu, but that is me. As for Mandrivia, I know little about it.
My personal recommendations out of all the ones I have mentioned would be for the average user either Debian or Fedora. Debian for greater stability, but Fedora for better usability and possibly better support for new hardware. You can do more research at www.distrowatch.com.
Out of the popular distros the least user friendly are Slackware, Gentoo, Arch, Linux from Scratch (it's not really a distro, but a howto on putting a Linux system together from scratch) and probably a few others I can throw in the list. These three will guide you through what to do, but it is a lot of work to do it. It can be overwhelming for a beginner or even an advanced user like myself. I have never used Slackware, but I have tried. Gentoo I got running, and recently I tried to install it in a virtual machine, and the list of instructions was way to long and involved for someone with the amount of time I have. Arch was probably the easiest of the bunch, but it involves using the command line quite a bit. If you are up for a challenge, these would be the distributions to use. By the end you will know quite a bit about how Linux works.
We then have our server category. Normally for a server you do not want the latest, greatest, and fastest update cycle in the world. This means you will want to use something a little older with a little more trial than the average distro. Some distributions you would want to look at are Red Hat Enterprise Linux, Oracle Enterprise Linux, Debian, CentOS, and OpenSuSe. There are a few others I could mention, but these are probably the most stable as in few bugs. Red Hat, Oracle, and CentOS are all related to each other because Oracle and CentOS are derived from Red Hat. Debian stands on its own. OpenSuSe I know less about, and that is for a reason. I am not a fan of OpenSuSe because its package manager is slow and buggy, and the operating system reflects this fact in other areas. Red Hat you will have to pay a contract for updates and support, Oracle you will have to pay a contract for support, and CentOS you are your support. Debian is pretty respectable too, but Red Hat is the creme of the crop as far I am concerned. If you are on a limited budget, CentOS is the best way to go.
For a desktop system some of our other choices would be OpenSuSe, Fedora, Ubuntu, Debian, Mandrivia, and countless others. I am of the same opinion still on OpenSuse. Fedora is the latest, greatest, and fastest update cycle you can get. It is so fast, they call it the bleeding edge, and bleeding for a reason. There have been a few times where the bugs have been too much, and they get worked out within about a month of Fedora having a release most of the time. Sometimes it takes two or three months to get some of the bugs that bother you out. Otherwise it is a great desktop and it has been my primary distribution for the majority of my Linux experience with the exception of a semester. Ubuntu is based on Debian with a bit of a faster release cycle, but it is slower on updates than Fedora. Ubuntu makes heavy use of sudo which I think is fundamentally unsecure, but I will write more on that later. Ubuntu has a richer collection of software thanks to the fact it is based on Debian. Debian has a large software repository. Most open source projects will have a package somewhere in the Debian repository. I would vote using the Debian testing branch over Ubuntu, but that is me. As for Mandrivia, I know little about it.
My personal recommendations out of all the ones I have mentioned would be for the average user either Debian or Fedora. Debian for greater stability, but Fedora for better usability and possibly better support for new hardware. You can do more research at www.distrowatch.com.
Monday, January 10, 2011
The Unix File System: A Simple Design
Coming over from the Windows platform to a Linux/Unix platform can be challenging. I learned quickly there was some unlearning to do. One of the fundamental differences between Windows and Unix is how both treat storage devices and directory layout. As a competent user with Windows you get accustomed to knowing where programs go and temporary data is stored. It feels natural over time for things to go where they go. When you see the Linux operating system, it all seems so foreign, so strange. Where is the C drive? Where is Documents and Settings? Where are my programs? Where is everything?! And when a seasoned Linux user tries to explain it to you it takes time to sink in.
Part of the confusion is how Linux and Windows deal with storage devices or partitions for that matter. In Linux everything and I do mean everything is a file or folder. That sounds profoundly normal, but it's not. On Windows your hard disks and partitions on those hard disks are given drive letters and treated as devices rather than files. How could a device ever be a file? It's not. However the description of how to talk to the device is contained in a special file. This special file is used for the mount command to take this storage device or partition and attach it to the directory structure. An example of this is I have the /media directory for such a purpose. Let us say I want to take my USB drive and mount it. It will appear as /dev/sdb1. I run the mount command and the contents of my USB drive will show up in /media. To show how flexible this design is, I can have five hard drives with 20 different partitions on each and have all fit nicely under the tree structure on Linux. In Windows this would not be easy to do if not impossible since there are only 26 drive letters. The design has some advantages.
Now we need to explain the directory structure. Everything comes under what we call the / (root) directory. Here we have the directories /bin, /boot, /dev, /etc, /home, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /srv, /tmp, /usr, and /var. Windows users it seems foreign doesn't it? The moment you can admit that Linux is not like Windows and it is a whole different breed of operating system you will make progress. If you keep looking for ways to compare it to Windows, that will only hinder your progress in the transition. That said we can continue.
The directory structure is something like this: /bin holds some basic programs needed for repairing the system and bringing it up. Some of these programs list the contents of a directory, change directories, change permissions on a file, change ownership of a file, search for a specified file, provide the utilities for accepting commands, etc. Stuff most end users don't even see.
Next up is the /boot folder. This contains the different components needed to load the operating system on boot up. Here we have our boot loader which gives us the option to boot Linux. In this folder is contained the configuration for the boot menu like which operating system you would like to boot Linux, Windows, FreeBSD, or several flavors of Linux. The kernel is loaded from this partition in that an image of it is placed here. Normally this folder doesn't take any more than 100 MiB.
/dev holds all the files that describe how our devices work. We have a file that describes how to interface with the CD-ROM, how to interface with this partition and that partition, how to utilize the mouse, etc.
If you ever needed to change settings on a system that affect the whole system or turn on some options more than likely /etc is the place to do it. This is where all the configuration files are located for several different pieces of software. In the past if you wanted to add another resolution to your monitor (assuming it supports it) you would either use a graphical tool to do this or add it by hand, but all the same it made changes in the /etc/X11/xorg.conf file. Needless to say this is one of the folders used to tweak the system.
Whatever happened to Documents and Settings? Users can store their content in their account folder which is located in the /home directory. The user folders hold files that users create, copy, or download. It also houses user specific configuration files that make the settings I set specific to me and not everyone else. This is the folder you are going to be more acquainted with than any other.
/lib holds the different libraries that programs on the system use. These libraries contain functions (a programming element) that can be reused for different programs and even different purposes. /media is where the system mounts different file systems and devices. /mnt is used for temporary file systems.
/opt is sometimes used for certain programs that you install through a tarball or RPM. /proc holds information pertaining to the system and other things needed by the kernel. /root is the root users home directory, so it is just like having the root accounts folder in / instead of /home. /sbin is similar to /bin, but it contains more programs related to file systems, networking tools, and system administration to only be used by someone with root privileges. I have not figured out what /srv does exactly because on my system it is empty.
/tmp hold temporary files much like C:\Temp. /usr is a folder that shares a bunch of things. Here we have programs, documentation, source code, more program libraries, backgrounds, pictures, etc. This is similar to Program Files on Windows in a sense, but it is much broader than that. /var holds logs, messages, and job spools primarily.
So there you have it. Now you should have a rough idea of how the Linux/Unix file system functions. With this information you can diagnose problems more easily and find more information to help you. Again for more specific details type in man hier on the command line to view the layout page.
Part of the confusion is how Linux and Windows deal with storage devices or partitions for that matter. In Linux everything and I do mean everything is a file or folder. That sounds profoundly normal, but it's not. On Windows your hard disks and partitions on those hard disks are given drive letters and treated as devices rather than files. How could a device ever be a file? It's not. However the description of how to talk to the device is contained in a special file. This special file is used for the mount command to take this storage device or partition and attach it to the directory structure. An example of this is I have the /media directory for such a purpose. Let us say I want to take my USB drive and mount it. It will appear as /dev/sdb1. I run the mount command and the contents of my USB drive will show up in /media. To show how flexible this design is, I can have five hard drives with 20 different partitions on each and have all fit nicely under the tree structure on Linux. In Windows this would not be easy to do if not impossible since there are only 26 drive letters. The design has some advantages.
Now we need to explain the directory structure. Everything comes under what we call the / (root) directory. Here we have the directories /bin, /boot, /dev, /etc, /home, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /srv, /tmp, /usr, and /var. Windows users it seems foreign doesn't it? The moment you can admit that Linux is not like Windows and it is a whole different breed of operating system you will make progress. If you keep looking for ways to compare it to Windows, that will only hinder your progress in the transition. That said we can continue.
The directory structure is something like this: /bin holds some basic programs needed for repairing the system and bringing it up. Some of these programs list the contents of a directory, change directories, change permissions on a file, change ownership of a file, search for a specified file, provide the utilities for accepting commands, etc. Stuff most end users don't even see.
Next up is the /boot folder. This contains the different components needed to load the operating system on boot up. Here we have our boot loader which gives us the option to boot Linux. In this folder is contained the configuration for the boot menu like which operating system you would like to boot Linux, Windows, FreeBSD, or several flavors of Linux. The kernel is loaded from this partition in that an image of it is placed here. Normally this folder doesn't take any more than 100 MiB.
/dev holds all the files that describe how our devices work. We have a file that describes how to interface with the CD-ROM, how to interface with this partition and that partition, how to utilize the mouse, etc.
If you ever needed to change settings on a system that affect the whole system or turn on some options more than likely /etc is the place to do it. This is where all the configuration files are located for several different pieces of software. In the past if you wanted to add another resolution to your monitor (assuming it supports it) you would either use a graphical tool to do this or add it by hand, but all the same it made changes in the /etc/X11/xorg.conf file. Needless to say this is one of the folders used to tweak the system.
Whatever happened to Documents and Settings? Users can store their content in their account folder which is located in the /home directory. The user folders hold files that users create, copy, or download. It also houses user specific configuration files that make the settings I set specific to me and not everyone else. This is the folder you are going to be more acquainted with than any other.
/lib holds the different libraries that programs on the system use. These libraries contain functions (a programming element) that can be reused for different programs and even different purposes. /media is where the system mounts different file systems and devices. /mnt is used for temporary file systems.
/opt is sometimes used for certain programs that you install through a tarball or RPM. /proc holds information pertaining to the system and other things needed by the kernel. /root is the root users home directory, so it is just like having the root accounts folder in / instead of /home. /sbin is similar to /bin, but it contains more programs related to file systems, networking tools, and system administration to only be used by someone with root privileges. I have not figured out what /srv does exactly because on my system it is empty.
/tmp hold temporary files much like C:\Temp. /usr is a folder that shares a bunch of things. Here we have programs, documentation, source code, more program libraries, backgrounds, pictures, etc. This is similar to Program Files on Windows in a sense, but it is much broader than that. /var holds logs, messages, and job spools primarily.
So there you have it. Now you should have a rough idea of how the Linux/Unix file system functions. With this information you can diagnose problems more easily and find more information to help you. Again for more specific details type in man hier on the command line to view the layout page.
Saturday, January 8, 2011
Secure While Away From Keyboard
Security is something we all value and treasure. We like knowing the front door to our home is locked when in the cities, we appreciate the safety of our valuables in our vehicles, and we are strict guardians of our privacy. If you use Linux there may be a gap you are not aware of, just as I was not aware of it.
If you use wireless, an email client, chat client, or anything else the system might ask if it wants to save your password (or in my case doesn't); you could be vulnerable to having your passwords retrieved while you are absent. What am I talking about? The program that manages your passwords and encryption keys called Seahorse sometimes by default leaves your passwords in an accessible unlocked state in a folder called login. From here I can retrieve on my system my passwords for my Google and Hotmail accounts. This is rather discomforting for someone like me since I am a network administrator. If my passwords get leaked, that could mean serious trouble.
For the past month or two I have been paranoid about this discovery resulting in a prompt lock of my laptop's screen until my return. It's a good policy anyway, and I will continue to do it, but you can have a password required to use the keyring by right clicking on this folder and telling it to lock. The password to unlock it or use the keyring is your user account password. You can change this password which I have done to enhance security.
This makes me feel a little easier about my passwords and should help me sleep better in the future. I hope it does the same for you. I will mention more things you can do to keep the system secure in another article.
Update: January 13, 2011
Apparently every time you type in the password it unlocks that folder. For a little while I felt more secure. I am still looking into how to lock this program up, and there has been some discussion on the Seahorse mail list to implement password protect to view passwords. http://mail.gnome.org/archives/seahorse-list/2009-November/msg00005.html
Update: March 27, 2013
I just read this blog post which states the issues with having password protection on the Keyring or in Seahorse itself. In summary if they did that you would have to enter your password any time an application needs access to the keyring, and Seahorse password protection alone would provide a false sense of security. The solution is to lock your screen before you leave which is what I have done for the past two years with the exception of Fedora 15 when lock was broken. Since I was one a few Linux users in my environment I switched to the terminals you can get to using Ctl+Alt+F1-6. Only two or three people knew what they were looking at when I did that, so it was reasonably safer but not entirely.
If you use wireless, an email client, chat client, or anything else the system might ask if it wants to save your password (or in my case doesn't); you could be vulnerable to having your passwords retrieved while you are absent. What am I talking about? The program that manages your passwords and encryption keys called Seahorse sometimes by default leaves your passwords in an accessible unlocked state in a folder called login. From here I can retrieve on my system my passwords for my Google and Hotmail accounts. This is rather discomforting for someone like me since I am a network administrator. If my passwords get leaked, that could mean serious trouble.
For the past month or two I have been paranoid about this discovery resulting in a prompt lock of my laptop's screen until my return. It's a good policy anyway, and I will continue to do it, but you can have a password required to use the keyring by right clicking on this folder and telling it to lock. The password to unlock it or use the keyring is your user account password. You can change this password which I have done to enhance security.
This makes me feel a little easier about my passwords and should help me sleep better in the future. I hope it does the same for you. I will mention more things you can do to keep the system secure in another article.
Update: January 13, 2011
Apparently every time you type in the password it unlocks that folder. For a little while I felt more secure. I am still looking into how to lock this program up, and there has been some discussion on the Seahorse mail list to implement password protect to view passwords. http://mail.gnome.org/archives/seahorse-list/2009-November/msg00005.html
Update: March 27, 2013
I just read this blog post which states the issues with having password protection on the Keyring or in Seahorse itself. In summary if they did that you would have to enter your password any time an application needs access to the keyring, and Seahorse password protection alone would provide a false sense of security. The solution is to lock your screen before you leave which is what I have done for the past two years with the exception of Fedora 15 when lock was broken. Since I was one a few Linux users in my environment I switched to the terminals you can get to using Ctl+Alt+F1-6. Only two or three people knew what they were looking at when I did that, so it was reasonably safer but not entirely.
Monday, January 3, 2011
Documentation is not a bad thing...
Documentation is something that some people appreciate and others do not. I was among the class of those that did not. Using Linux put me in the class that did. Learning to appreciate documentation early on will help save you many a headache with using this operating system. Before I point you to resources that you can use, I will share some of my misfortunes.
As a Windows user I was accustomed to playing with settings until things would work the way I wanted them to. Doing this normally resulted in no injury to the system. The habit continued even into using Linux. Linux however fixed that. After I installed Fedora Core 4 in December of 2005 I quickly found I had some tweaking to do to get things working, but the graphical interface didn't seem to tweak or configure much. I soon found the only way (at the time) to get my video driver and wireless drivers working properly would involve using the command-line. I used it and installed my video driver first, rebooted the system, only to find my monitor displaying an interesting message telling me "Out of Range." My new Linux installation was now not accessible, or so I thought. Time for a clean install. I did that clean install a total of three times only to find that the problem was with how the driver tweaked my xorg.conf file. I had to manually set my monitor's refresh rates to avoid that problem. If I had read up on possible issues with xorg.conf, I could have possibly avoided the three reinstalls and made progress with setting up my system.
Another time that reading documentation is helpful is when a warning pops up on the program you are using. As a new Linux enthusiast and comfortable user I thought I could handle setting labels on my different partitions since I ran three or four different distributions. I used gparted (might have been the PartitionMagic clone) and clicked on setting the disk label (this is much different than changing the label on your partitions). A warning popped up which I thought was nothing because we are setting a new label and as a result just closed it without reading it (bad move). Not long after setting the new disk label all partitions that were in view disappeared. I had just changed the system that kept track of the partition tables and as a result all partition on that hard disk were now gone. I realized the mistake I had made and hoped it wasn't applied, so I rebooted only to find that even Grub had disappeared. Thankfully no important data was lost, and the only thing that was hurt was my pride.
So if you ever read in a support forum or chat channel the expression RTM or read the manual, please take it to heart. It is never a bad thing and yields more good than evil. Documentation is your friend in this new world because this new world will let you do anything, and only sometimes does it let you know you are about to get into trouble. Place high value on those manual pages and other resources.
The man and info commands are fairly helpful. If you are looking for quick answers Google is normally more helpful, but sometimes if you know what you are looking for the man pages are a help too. Using info will help with most GNU packages such as emacs, info, bash, etc. You can pull up a directory of all info documentation on your system by only typing info at the command prompt. To find out more about how to use man or info just type in the commands "man man" and "man info."
If you are looking for more friendly guides than manual and info pages, some other resources may be in order. The Linux Documentation Project (www.tldp.org) has excellent guides, tutorials, how-tos, and also all the man pages. O'Reilly (oreilly.com) is a publisher that most high quality books on Linux and other free/open source packages come from. Forums specific to your distribution are another great place to find help.
Hopefully you can avoid the same pitfalls and others that I ran into as a new Linux user. Expect to need to do some reading or a lot of time repairing your system without it. These days using your system the way I used Windows is a little safer now thanks to the administrative tools for Ubuntu and Fedora. When I started we were beginning to make the transition and I sit among those who know how to use the command-line. Your experience should be more pleasant.
As a Windows user I was accustomed to playing with settings until things would work the way I wanted them to. Doing this normally resulted in no injury to the system. The habit continued even into using Linux. Linux however fixed that. After I installed Fedora Core 4 in December of 2005 I quickly found I had some tweaking to do to get things working, but the graphical interface didn't seem to tweak or configure much. I soon found the only way (at the time) to get my video driver and wireless drivers working properly would involve using the command-line. I used it and installed my video driver first, rebooted the system, only to find my monitor displaying an interesting message telling me "Out of Range." My new Linux installation was now not accessible, or so I thought. Time for a clean install. I did that clean install a total of three times only to find that the problem was with how the driver tweaked my xorg.conf file. I had to manually set my monitor's refresh rates to avoid that problem. If I had read up on possible issues with xorg.conf, I could have possibly avoided the three reinstalls and made progress with setting up my system.
Another time that reading documentation is helpful is when a warning pops up on the program you are using. As a new Linux enthusiast and comfortable user I thought I could handle setting labels on my different partitions since I ran three or four different distributions. I used gparted (might have been the PartitionMagic clone) and clicked on setting the disk label (this is much different than changing the label on your partitions). A warning popped up which I thought was nothing because we are setting a new label and as a result just closed it without reading it (bad move). Not long after setting the new disk label all partitions that were in view disappeared. I had just changed the system that kept track of the partition tables and as a result all partition on that hard disk were now gone. I realized the mistake I had made and hoped it wasn't applied, so I rebooted only to find that even Grub had disappeared. Thankfully no important data was lost, and the only thing that was hurt was my pride.
So if you ever read in a support forum or chat channel the expression RTM or read the manual, please take it to heart. It is never a bad thing and yields more good than evil. Documentation is your friend in this new world because this new world will let you do anything, and only sometimes does it let you know you are about to get into trouble. Place high value on those manual pages and other resources.
The man and info commands are fairly helpful. If you are looking for quick answers Google is normally more helpful, but sometimes if you know what you are looking for the man pages are a help too. Using info will help with most GNU packages such as emacs, info, bash, etc. You can pull up a directory of all info documentation on your system by only typing info at the command prompt. To find out more about how to use man or info just type in the commands "man man" and "man info."
If you are looking for more friendly guides than manual and info pages, some other resources may be in order. The Linux Documentation Project (www.tldp.org) has excellent guides, tutorials, how-tos, and also all the man pages. O'Reilly (oreilly.com) is a publisher that most high quality books on Linux and other free/open source packages come from. Forums specific to your distribution are another great place to find help.
Hopefully you can avoid the same pitfalls and others that I ran into as a new Linux user. Expect to need to do some reading or a lot of time repairing your system without it. These days using your system the way I used Windows is a little safer now thanks to the administrative tools for Ubuntu and Fedora. When I started we were beginning to make the transition and I sit among those who know how to use the command-line. Your experience should be more pleasant.
Subscribe to:
Posts (Atom)