Linux System Administration
When you booted up your Linux machine, you instantly became the System Administrator. You may have fewer users, or you may not be connected to a network, but many of the functions are similar. Perhaps the only difference is that you know whom to complain to when the system is not configured properly. As this series continues, you should be able to get a good grasp on what you have to do to make your system efficient, secure and user-friendly. And you'll know how to do it.
When you have your machine set up, log in as root. By default, the root user has no password. So when you are asked for a password, just hit the ENTER key. This makes it easy to log in, as you don't have to go hunting around for a password after you set your system up. The disadvantage to this is that anyone can log in as root and have free access to your system. The first thing you must do is to change the password for root. To do this, use the passwd command. The root's password must be impossible to guess by normal users. Also, user accounts should be protected with just as much security. Here are some hints for good passwords:
1. Do not include anything significant to you, such as a nickname, phone number, your last name, etc.
2. Change your password often. (especially if you are on a network).
3. Do not use a word that can be found in a dictionary.
4. Make your password at least 6 characters long, with a mix of letters, digits, and/or punctuation characters.
5. Do not tell anyone your password and don't write it down anywhere.
6. Change your password often (just in case you forgot).
To change your password, type: passwd
Type in your password; then you will be prompted to type it in again just to make sure you spelled it right the first time. If the two passwords you entered do not match, your password is not changed. When you type in your password, it will not be shown on the screen. This is to prevent anyone around you from seeing your password.
A sample password changing run looks like this:
# passwd Changing password for root Enter the new password (minimum of 5 characters) Please use a combination of upper and lowercase letters and numbers. New password: Re-enter new password: /#
Now that your system is more secure, make your system more user-friendly. One way of doing this is by changing two files, /etc/issue and /etc/motd. The /etc/issue file contains the message that you see above the login: prompt. This messag e sometimes contains the name of the site and the operating system. For example, my /etc/issue file reads:
linux ver. 0.99.14 (enry)
The next file you'll want to change is /etc/motd. This file is the one that gets seen every time you log in. Motd stands for Message Of The Day. This file usually contains a welcome screen and messages of general importance for all users. For example, my /etc/motd file has:
** Welcome to enry ** Good News! SLIP will be available Real Soon Now. Send mail to root for more information.
These are just examples. Your setups may look similar to this, but they don't have to be. There are other ways of making the system easier for other users (and yourself). For starters, you may want to look at the man pages for bash, X, and any other kinds of utility programs you may be using. The man pages are a good source of information.
The idea of a drive in UNIX is much different than it is under DOS. The Linux (and UNIX) way of looking at drives is as follows: Each physical drive can be split into partitions (or filesystem), and each partition can be mounted into a directory.
Because of this, there are no drive letters as in DOS; there is no drive A:, B:, C:, and so on. The users will be dealing with only one drive, and everything is shown in terms of directories to the user. You could have one filesystem for the root directory and other files (the / directory), another filesystem for user commands (the /usr directory) and another filesystem for user space (the /usr/users, /home, or /user directory). For example, I have three partitions that I use: one is for the / directory, one is for the /usr directory, and the third one is for the /home directory.
When I cd into the /usr or /home or / directories or any of their subdirectories, it is just like using cd from DOS to change to a subdirectory. I do not have to switch drive letters; I just have to use cd and I automatically go to that filesystem.
There are a few advantages to using this system. First, you can add more total space to the system. If you notice that the /usr/X386 subdirectory will take up more space than /usr has, you can create a new filesystem from the unused portion of your drive and mount that partition to /usr/X386. Second, all file operations are invisible to both the user and the user's programs. DOS needs a drive letter and a directory. Linux just needs a directory.
Linux refers to physical drives, such as the 3.5 inch floppy drive, as files in the /dev directory. For example, the first drive (called A: in dos) is /dev/fd0 in Linux. The fd refers to the fact that it is a floppy drive, and the 0 means that it's the first of that kind of device. Hard drives are referred to in two different ways. One way is the physical drive itself, the first or second (or more) drive. The other way is by partition on that physical drive. Hard drive entries in /dev are prefixes with hd to signify hard drive, followed by an an “a” for the first physical drive “b” for the second physical drive, etc. After that, a number specifies the partition within the physical drive. The first partition is 1, the second partition is 2, etc. SCSI devices follow the same format, only their prefix is s. You can remember that asSCSI device.
In order to help you think in Linux, here are a few DOS to Linux ways of thinking of the same drive:
DOS LINUX A: /dev/fd0 B: /dev/fd1 C: (assuming first /dev/hda1 partition on the first hard drive) E: (assuming second /dev/hdb2 partition on the second hard drive)
In my next article I'll discuss making our own filesystem (in ext2 and xiafs formats), and I'll go over some of the entries in the inittab file. If you have any questions or comments about my article, I can be reached through e-mail at: firstname.lastname@example.org or via mail through Linux Journal.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide