Slashdot Mirror
Learning More About Linux?
teh moges asks: "From an administrator point of view, I know a lot about Microsoft Windows: where files are stored, where settings are, which registry keys to edit, how to change drivers, and so on. I made the initial switch to Linux a year ago. I now feel capable enough with using Linux, from an end user's point of view, so that when things go wrong, I can fix them. I now want to become even more familiar with Linux. Are there any great resources, such as websites, wikis or books for someone that wants to find out exactly how Linux works and how to fix and modify it?"
Linux is files. The entire OS is based on files. Things to run on startup? Files. Opening hard drives? Files. Drivers? Files. (kernel mods)
No magical black box registry, windows drivers, etc. Once you understand this, other things will come easier.
Sure thing.
Get yourself a Haynes manual for your model vehicle.
I was in a similar situation about a year ago, and I found that the best way to learn about the guts of the system, so to speak, was to pick up Gentoo, which is something of a "Roll your own" kind of Linux distribution.
Now, by no means do I recommend this for day to day use. I love Gentoo, but it breaks. Frequently. And unless you know a fair bit about how the system works, you'll end up breaking it quite often yourself. This is a good thing, and introduces you to the various configuration files, locations of critical items, how everything slots together, and how to compile your own kernel. The Gentoo documentation is excellent, and if you go about it with a certain goal in mind (web server, router, media center) you'll end up learning a fair bit about Linux in the process.
LFS
Check out http://www.linuxfromscratch.org/livecd/ and http://www.linuxfromscratch.org/lfs/
Try creating a distro of your own and you should get a handle on the mysteries of the OS. If you don't have spare hardware check out virtualbox.org and try creating your lfs distro on a virtual x86 computer
http://nyamenation.org/
I've learnt oodles about all OSs by breaking them. Delete something. see how it changes the behaviour of the system. If it was somethign really important, you'll learn about system recovery, otherwise, trouble shooting.
I'm serious.
Really. Just use it. Like many other things, the best way to become familiar with Linux is to use it for your daily tasks for a while, and find out how to fix any problems you run into. I've used a dual-booted machine for some time, and about 6 months ago I made the decision to switch my main OS over from WinXP to Linux, and relitively painlessly went from dabbling to a being well versed pro user in a few months.
I dont have one magic answer.
Forums are good for getting and sharing information on specific problems as long as the "google it yourself" crowd havent invaded. (how else would you have found the forum?). http://www.linuxquestions.org/ is a good start.
There are varias wiki's specific to certian subjects.
And I dont mean to sound rude with this, but please read the man page first. Weather or not you understand it at the time.
On a side note the best way I have found to learn about something is to break it first. but maybe thats just me.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
XXX#######
I have found that http://gentoo-wiki.com/ is a great resource for knowledge about the basesystem itself of Linux. I do love my Gentoo of course, but you'll find resources on said wiki for Linux in general - and quite a few of them - and I've seen people from both the Debian and Ubuntu community also look to this Wiki from time to time.
God does not play dice - Albert Einstein
use Chilton's
In part 2 we'll be looking at installing XFCE and removing the embarrassment that is Gnome. Until next time...
If you really want to know this stuff, there's no substitute for Linux From Scratch. You build the entire system piece-by-piece.
Here is what I got, take it for what it is worth.
m l/
See 'man Linux Filesystem Hierarchy'. In case for some reason that doesn't work on your system, here is a link -> http://tldp.org/LDP/Linux-Filesystem-Hierarchy/ht
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
http://tldp.org/
this is the linux doc proj the one place i found indispensable while learning slackware back in the day
lately http://www.debuntu.com/ is a god send as well
and of course , unlike windows software, most linux software readme files are actually filled with useful information
othjer than that either a quick google on a specific question or jump onto irc will usually get you some help
back in the day we didnt have no old school
I fancied myself a Windows "power user" and then GNU/Linux was foisted upon me because of a hardware crash. My backup system wasn't good enough to run XP, so I tried Red Hat 9. It certainly was a bitch, but I leaned GNU/Linux by doing the same thing I did when I was learning Windows: poke and prod at the system and see what changed. Doing is the best way of learning.
Don't really worry too much about a specific distro. I went from RH9 to Fedora Core to Ubuntu to Debian over the span of about 4 years. Once you learn enough, you can pick up any distro without too much hassle.
My best advice is to pick a distro and dual boot with XP/Vista. Every day try to use your GNU/Linux distro a bit more each day. Be sure to try to fiddle with settings. Just make sure you have a backup ready for any important data. For awhile there, I was reinstalling the OS weekly. Don't be afraid to experiment.
O'Reilly publishes any number of books that will suit your needs, covering everything from the basics on down to the most esoteric.
First of all, you should have in mind that Linux is just a kernel, and what you are probably more interested in are all the userland programs that comprise your typical Linux distribution. I think it is best to start with a general Unix introductory text, because the fundamental principles have not changed in 25 years, and it is much better to understand the core Unix system utilities and how they plug together to accomplish complex tasks, rather than waste time with all the modern Windows-like interfaces that are fashionable in Linux distributions today.
There is one "classic" Unix introduction book that I can strongly recommend, and that you can probably buy used for a dollar: Exploring the Unix System by Stephen Kochan and Patrick Wood. Make sure to get the paperback edition that is about 400 pages. Also, apparently the authors are going to release an updated version of that book -- check http://www.kochan-wood.com for updates.
Once you learn the fundamentals of Unix systems, then you would be ready to learn the modern tools available in Linux distributions. Remember that is much more important to learn the principles and philosophy that Unix was built upon, rather than attempting to memorize arcane details.
Bush Lies Watch
issue the following commands /bin /usr/bin /usr/local/bin
/sbin /usr/sbin /usr/local/sbin
part 1:
$ cd
$ for binary in * ; do man $binary ; done
$ cd
$ for binary in * ; do man $binary ; done
$ cd
$ for binary in * ; do man $binary ; done
part 2:
$ su -
Password:
# cd
# for binary in * ; do man $binary ; done
# cd
# for binary in * ; do man $binary ; done
# cd
# for binary in * ; do man $binary ; done
# exit
Don't take a long time doing this, and more specifically DO NOT ATTEMPT TO MEMORIZE EVERYTHING. Just skim the man pages. You'll get a feel for what programs are available. Then read the man page for apropos so you can jog your memory later.
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
Your best bet is to start with Slackware 11, it's a manual distribution which will force you to actually get involved with it and learn how things work under the hood.
a re-11.0-iso/)
For example, you have to write your own iptables firewall script. But by doing this, you'll be able to understand the output of "iptables --list" on any distro out there and see what it's doing behind the scenes (for instance, amusingly, what holes does it leave open if any?).
You can download the distro here, for free:
http://www.slackware.com/
(my favorite mirror is: http://slackware.cs.utah.edu/pub/slackware/slackw
There's a good book on it available here: http://www.slackbook.org/
Think of it this way (using a car analogy like the other guy, but more seriously):
If you learn to drive in a car with a five speed stick and a clutch, you'll be able to drive almost any wheeled vehicle on Earth with very little futzing around. It's almost like having a superpower.
But if you start out driving an automatic, you'll ONLY be able to drive automatic until somebody teaches you manual. And you won't have any reason to learn it, so you'll miss out on a potentially important skill.
It's better to start out with something challenging and switch to the easy stuff later.
Go Slackware, be a nerd like us! You'll thank me later.
NO CARRIER
Just for you, my very own iptables firewall script! If anyone notices anything I left out, please let me know and discuss!
/etc/rc.d and named "rc.firewall".
(start here):
# Script by SADGEEKHERMIT, based on an earlier script I wrote for FreeBSD/ipfw.
# This firewall script should be placed in
# Assumptions: you're using iptables, and your computer is a workstation
# which isn't making any services available to the web. Also you're paranoid.
# First, clean out the current ruleset.
iptables --flush
# Now for the initial admin part.
# Policies (what isn't explicitly allowed is automatically denied):
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
# Allow all local, loopback traffic:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Block malformed "XMAS" and "NULL" packets:
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# Block ping:
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP
# Permit DHCP!!!
iptables -A OUTPUT -p udp ! -o lo --dport 67 -j ACCEPT
iptables -A INPUT -p udp ! -i lo --sport 67 -j ACCEPT
# Permit DNS:
iptables -A OUTPUT -p udp ! -o lo --dport 53 -j ACCEPT
iptables -A INPUT -p udp ! -i lo --sport 53 -j ACCEPT
# Permit ICMP type "destination unreachable":
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
# Now for our internet access rules. These will explicitly permit
# web browsing, passive-mode FTP, etc.
# The way this works is, for every TCP port you want to use,
# you add these two lines (replacing N with the port number):
# iptables -A OUTPUT -p tcp ! -o lo --dport N -j ACCEPT
# iptables -A INPUT -p tcp ! -i lo --sport N -m state --state ESTABLISHED,RELATED -j ACCEPT
# For a workstation/home computer, you'll want to make these ports available:
# 80 (HTTP), 443 (HTTPS), 110 (POP3), 143 (IMAP), and 25 (SMTP).
# NOTE: Doing it this way means we don't have to explicitly block anything.
# If we don't allow it, it's blocked. For example, if you're not on the loopback
# interface (localhost, lo) you can't access X at all (tcp ports 6000-6020).
# Internet access rules:
iptables -A OUTPUT -p tcp ! -o lo --dport 80 -j ACCEPT
iptables -A INPUT -p tcp ! -i lo --sport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp ! -o lo --dport 443 -j ACCEPT
iptables -A INPUT -p tcp ! -i lo --sport 443 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp ! -o lo --dport 110 -j ACCEPT
iptables -A INPUT -p tcp ! -i lo --sport 110 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp ! -o lo --dport 143 -j ACCEPT
iptables -A INPUT -p tcp ! -i lo --sport 143 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp ! -o lo --dport 25 -j ACCEPT
iptables -A INPUT -p tcp ! -i lo --sport 25 -m state --state ESTABLISHED,RELATED -j ACCEPT
# FTP RULES:
# FTP is a special case. You would NEVER allow non-passive FTP, because
# then you'd have to open up all YOUR high ports from 1024-65,535. Why even HAVE
# a firewall? On the other hand, passive FTP is a lot safer; you're allowing traffic TO
# port 21 on the remote server, and traffic TO and FROM high ports on the remote
# server. This doesn't open up ANY local ports on this machine; it just means you
# can talk to high ports on the remote machine, which isn't all that bad.
# So here are the rules for PASSIVE MODE FTP:
iptables -A OUTPUT -p tcp ! -o lo --dport 21 -j ACCEPT
iptables -A OUTPUT -p tcp ! -o lo --dport 1024:65535 -j ACCEPT
iptables -A INPUT -p tcp ! -i lo --sport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
NO CARRIER
If you are on a linux system:
$man man
If you are on the web:
http://tldp.org/
http://en.wikipedia.org/wiki/Linux
Cogito, ergo sum
I'm just a nerd, not part of the Slackware project per se, and although I dearly love Slackware, this opinion is purely my own and not designed to benefit anyone or any distro or anything except YOU who might really dig it.
:)
Just thought I'd mention that!
Sorry for all the posts.
NO CARRIER
When I was learning about Linux, back in the mid-90s, the most valuable resource I found was The Internals of the 4.3BSD Operating System by McKusick, Quarterman, Leffler and Karels. This book acquainted me with the design goals of unix-like operating systems, and the issues of implementing these patterns.
Also, I'd pick either Aileen Frisch's Essential System Administration or UNIX System Administration Handbook by Evi Nemeth.
Fast forward to the 21st century, I now spend the bulk of my time using FreeBSD.
Linux is great, but remember that the thing that makes it great is that it's a unix-like OS. Learning the skills to be comfortable on Linux, Solaris, *BSD, HP-UX, AIX, or whatever the flavor of the day, will take you further than limiting yourself to just one.
Good luck!
exactly how Linux works and how to fix and modify it?
When you say 'linux' do you mean
The Kernel?
A kernel + userland?
A kernel + userland + other programs that run in that environment?
The USPO says that Linux is a branding for soap, so is that what you seek?
Linux From Scratch. This is a project which maintains and outlines the knowledge of how to manually compile a Linux system from source code. In other words, it's about as fundamental as you can get.
The project is also run by some really awesome people...probably the most decent that I've come across in the Linux community.
A lot of people say that Gentoo is compiled for your system and thus results in a massively faster system. This only has some truth to it. They also say that Gentoo allows for a much deeper understanding of linux and how their computer works. This is even less true. There used to be a site up making fun of gentoo users who think they are bad ass by using gentoo, but I believe it is MIA now. You can browse this thread to get the jist of what it said: http://forums.gentoo.org/viewtopic.php?t=181330&po stdays=0&postorder=asc&start=0
I'll admit that Gentoo is far harder to get running then say, Ubuntu, but by no means does it make you an expert. At the least, it makes you really efficient at copying-pasting errors in google... at the most... ???
Although, I run it on my laptop, and it took a bit of time to get everything working. Would I switch distros? no, I like it a lot.
Linux Documentation Project ~ Rute User's Tutorial and Exposition ~ Linux Newbie Administration Guide ~ LinuxCommand.org ~ Linux From Scratch ~ FreeBSD Hypertext Man Pages for Red Hat 9
Read man pages or if you are on a Red Hat/Fedora system info and pinfo are great.
Choose a distro you feel comfortable with, see what you can change and how this affects the system.
Good luck
-- "Genius is 1% inspiration and 99% perspiration" - TAE --
There are probably some good books out there, and I hope you get some recommendations for them, but there is one key thing that you should learn about Linux that will get you 99% of everything you'll ever need to know about how your system works: How it boots.
If you understand how everything gets started you'll understand how it all fits together, and, even better, you'll have the starting point you need for tracking down anything else you need to figure out. And the great thing is that it's simple enough to described reasonably completely in one brief slashdot post.
The boot process consists of the following steps:
That's it. All you have to do is go read that shell script and you'll find out how absolutely everything running on your system gets started, from the file systems that are mounted to the network devices that are configured to the graphical user interface. Of course, along the way, you'll run across dozens of commands and hundreds of configuration files that you'll have to look up, but with 'man' and a little persistence you will gain an understanding of each major component, where it lives, what it does, how it gets started, restarted, killed and modified.
Even better, you don't have to worry about understanding it all at once. Once you find the /etc/init.d/rc script, and see how it executes all of the other scripts in /etc/init.d, you'll be well equipped to track down the answer to any question you have about how your system works. Sometimes getting an answer will mean traipsing through a few levels of indirection, but all the information is there. No magic, nothing hidden, all there for your perusal and/or modification.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
- even if it's not documented, you _have_ access to the source
- even if you do not have time to access/read the source, the problem are usually in the open, generally discussed by someone else you could easily locate. If you are the first one, someone is usually going to answer you.
On linux, most of the configuration is done in _text_ files, and most of the system set-up is done by sh/bash shell script. Get familiar with shell scripting (it's a minimal requirement anyway), and you usually can read you way through. For example, it's a very good way to understand how the system starts, in details.Of course, RTFM/RTFMan is always a good idea, but usually, a " --help" gets you through most of the time.
Now, of course, not everything is a shell script, and you do not have the time to study the manual pages or the documentation. Make sure that you have various tracing tools (system/network/etc):
Using those tools on misbehaving/unknown programs is going to give you some insight on how they work, and _what_ exactly they are doing. Their output can really be intimidating, but once you get some minial knowledge about protocols and other inner workings
And of course, having some basic idea in programming in the langague of you main applications is going to be helpful, but that really depend on how much time you want to devote to it and how programming-inclined you are.
Never forget that the unix philosophy is not about monolythic applications, but rather distributing tasks to smaller utilities. So learn about all those funny commands that are displayed when you press any keyboard letter and . You are going to be surprised: did you know that linux has "cut" and "paste" has commands ?
[Pruneau
The best way to learn a foreign language is total immersion. It's the same with GNU/Linux. Pick a distribution and start using it for everything. You'll pick it up soon enough.
Is to take a class at your local college or University. That's better than any book you could buy or forum you could visit. It really makes you process and apply what you learn, as well as making sure your education is well rounded. The UNIX classes at my college have no prereqs, and cater to career professionals in atmosphere, attitude, and availability and applicability. I'm sure you can do just as well if you take a look.
The De Facto credo of Slackware is KISS, Keep It Simple Stupid.
ALL configuration file are plain text files that can be eddited manualy.
Slackware always uses a plain vanilla Kernel, never pached.
Slackware has a policy of incorporating only stable releases of applications, standing mainly for design stability and aims to be the most UNIX-like Linux distribution. Doug McIlroy summarized the UNIX philosophy in three simple rules:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
Slackware Linux does not have a complex package manager like RPM or dpkg. Packages are normal tgz (tar/gzip) files, often with an additional installation script and a package description file. For novice users tgz is much more powerful than RPM, and avoids dependency problems.
Slackware uses BSD style init scripts, while most other Linux distros use System V style init scripts. Basically, with System V style each runlevel is given a subdirectory for init scripts, whereas BSD style gives a single init script to each runlevel. BSD style advocates say that it is better because with this system it is much easier to find, read, edit, and maintain the scripts. System V advocates say that the System V structure for the scripts makes them more powerful and flexible.
It is worth noting that System V init compatibility has been incorporated into Slackware, starting with version 7.0.
Thea way I put it is that Slackare is is lean, mean ant to built to stay that way.
From time to time I'll visit http://librenix.com/, a "linux tutorial" aggregator site where people collect various tips about Linux and its various applications. This is often how I will hear about various applications, methods to secure your computer, tricks for administering Linux, etc. For example, as of this writing, among the first page list of articles we have a tutorial on installing VirtualBox in Linux, emacs essentials, how to install dual monitors, etc. Most articles are good, although the styles can vary since Librenix just points to various web pages; they weren't created for Librenix itself.
Recommended.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Thanks for the replies, it seems I have alot to read. I am going to head off to Linux From Scratch and start with what they have there, and see how that goes. Depending on how that goes, I'll go to Slackware and see what it has. Thanks also for the suggestions for books. Despite what is available on the net, theres always something extra when reading it from a book.
P.S. OSS is usually a moving target, in that it actually gets updated and things change, avoid "new" unless you need it, stay in the package tree. Use OSS and I'm saying this from a pragmatic view. Review hardware against your kernel, version of X, desktop environment, and your distribution. Make sure there's accurate documentation if you get into trouble, prefer hardware that releases their specs. Ask questions and go to a Lug meeting every once in a while. Buy Crossover office, don't try messing with Wine it's a PITA and I think they get more out of your money than your bug reports. Learn how to build rpm and deb packages, then you can go outside of your package tree, still avoid closed source 3rd party crap though, unless you install it with crossover. Finally, trust me, yes it's really worth it, it will even make you a better Windows user/admin. Of course this is what I've learned and what has been important to me, YMMV.
Under the influence of Post-Cyberpunk Gonzo Journalism
BOOKS:
m l
H andbook-3rd/dp/0130206016/ref=pd_bxgy_b_text_b/104 -2587738-8696715?ie=UTF8&qid=1176522696&sr=1-1
i nistration/dp/0201702711/ref=pd_sim_b_4/104-258773 8-8696715?ie=UTF8&qid=1176522696&sr=1-1
i n-Mako/dp/0132435942
Essential System Administration By Æleen Frisch
http://www.oreilly.com/catalog/esa3/index.html
Unix Power Tools By Shelley Powers, Jerry Peek, Tim O'Reilly, Mike
Loukides
http://www.oreilly.com/catalog/upt3/index.html
Running Linux By Matthias Kalle Dalheimer, Matt Welsh
http://www.oreilly.com/catalog/runlinux5/index.ht
The UNIX Systems Administration Handbook by Evi Nemeth, Garth Snyder,
Scott Seebass, Trent R. Hein, et al.
http://www.amazon.com/UNIX-System-Administration-
The Practice of System and Network Administration by Thomas A.
Limoncelli, Christine Hogan
http://www.amazon.com/Practice-System-Network-Adm
Martin F. Krafft: The Debian System: Concepts and Techniques
http://debiansystem.info/
Benjamin Mako Hill, Jono Bacon, Corey Burger, Jonathan Jesse, Ivan
Krstic: The Official Ubuntu Book
http://www.amazon.com/Official-Ubuntu-Book-Benjam
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
Find and join your local Linux Users Group. Start here on GNU.org's List of Linux User Groups and see what you can find. Most of everything I know from Linux is either:
1. What I learned from my local LUG
2. What I learned from my best friend, the Linux Guru
3. What I learned from reading a multitude of books and websites
4. Through classwork at the local business college with a Linux-friendly IT program
Interact with people who know about Linux. Ask questions. Read HOWTOs. Get reference books and read them.
Come to slashdot everyday. You'll learn a lot about linux that way :)
The real key to unix (any unix) is knowing how to use the tools that you get installed with the OS to make your life easier.
.vimrc file I can create from memory that makes vi behave just as I like) - ok yes vim != vi, but to shock vi purists I like to be able to use the cursor keys while in insert mode!
First things first is the terminal (xterm, kterm whichever it doesn't matter) use it. Forget the GUIs, use the shell.
That brings us onto the shell itself. Pick one and stick with it for a while. On linux most people prefer bash, its a good choice as even though its not on all unixes by default its not difficult to obtain (just don't try to set the root users default shell to bash on solaris)
Learn the language of the shell, pipes, redirects, command line interpretation of special characters, handy tricks like tab complete, loops, variables, tests and use these all on one liners - progress to script files and also learn about functions - shell scripts are usually going to be fairly primitive tasks but they are the key to an easy life as an admin.
Man is your friend - and should always be the first place you turn for help, then google, then forums.
Learn the basic commands, ls, mv, cp, rm, learn their options and understand the justifications for using them (-i? -f?)
Pick an editor and learn to drive it - this is a long process but well worth it. Don't bother with a GUI one, consider that later. On a default linux install you will probably have vim and emacs - try them both, see which you like and use it. Check out guides on how to customise them until they behave just how you want them (I have a 10 line
learn atleast the basics of the other important tools - at the very least find and grep. Awk and sed should certainly be on the list as you will encounter many scripts that use them, atleast some basic knowlege of perl would be handy (I prefer to use perl instead of awk and sed but thats my preference not everyone would agree)
Set up services and experiment, run a webserver, database server, mail server and learn as much as you can stand to about iptables to secure your box.
Keep backups, don't be afraid to break things, fixing what you broke (after finding out what you did to break it) is some of the best education yuo can have
All in all
Have fun!!
$_="Slashdotter";$syn="OTT";s;..;;;sub _{print shift||$_};s!ash!Perl !;s=$syn=ack=i;tr+LLEd+BLAH+;_"Just Another ";_
i don't even want to count the number of times i've reinstalled xp (or on how many machines), but eventually i learned that putting all of my goodies on a single partition was making my life much harder. with knoppix, (a couple of differents forms of) gentoo and ubuntu (which i stick with because it is the easiest to get new users into, so i must know it) i have done so many reinstalls and have learned a lot about each os through the random changes i have made and the various problems that arose due to stuff that i didn't realize i had done.
best advice ever: keep your important data safe and secure somewhere. once you've done that... play. the odds are almost zero that what you do wrong will be irrepairable. my favorite thing to tell everyone that asks me to teach them how to handle something better: "i can only show you what i do, what i know works and doesn't; i can't teach you to be reckless, random, cautious and experimental."
If you have trouble finding explanations for how linux works, it's quite remarkable that you are able to grok how windows works AND being completely unable to use google. In fact, I don't believe you. If you had said you didn't want to learn something new, because you already had invested a lot of time in windows, I'd believe you. But that you can't find more about linux on teh Intarweb is far beyond disbelief. Either you must have absorbed your windows knowledge through osmosis or some other process not involving intelligence; or you have recently suffered a stroke or something that damaged your brains ability to work; or you are simply a troll. My money is on the latter. Because stuff to learn about linux is just a click away.
You must be new here.
I'm sure there's a lot of early *nix users who will find the information in this thread particularly helpful.
F_T
All I did was find a a social interest group that re purposes IT kit for use by charities and the like, strips it down, rebuilds it and installs Linux on it, and servers too. It does two things, firstly, it keeps computers out of landfill and secondly it helps people less fortunate than myself learn and use computing, kinda like freegeek, but for charities! Just think of the massive array of different kit you could get to play with!
http://www.writeitfor.us - Writing IT for the IT generation.
If it ain't broke, break it. Fix it. Understand it.
Here's some things to try:
Compile mplayer. Build a firefox package for your distro. Download, patch and compile a kernel. Add a cronjob to delete some files at random. Forget about it. Try and restore them. (ext2 does not delete file pointers in inodes). Create an LVM group. Siphon disk space between disks and partition. Try a file system written by someone suspected of murder. Post on a linux-devel list and join Linus in slagging off Gnome. Try KDE and XFCE and decide no-one needs a desktop environment. Try some ultra minimal *box window manager. Live in the terminal for a week. Log in to your computer using SSH from afar and wonder why when you play music you can't hear it. Rsync something. Write your own superior syncing script. Write some perl scripts. Python. Add a RAID. Try an old 2.4 kernel..
One thing I've found useful is to expose myself to a variety of different distributions. A lot of the stuff you want to know for system administration is subtly different from one distro to another, and so switching distributions will call your attention to it. Startup and daemon-control scripts, for instance, are not quite the same on any two distributions, but after you've used about twelve different ones, you'll get a feel for the things that *are* the same about them through all the different systems.
... when you are starting to feel comfortable with that, then you can move on to a new project.
I'd recommend making sure you've used at least one rpm-based distro, at least one apt-based distro, at least one binary-package distro that doesn't use rpm or apt, and at least one source-based distro. Oh, and also, run off a live CD for a month or so sometime.
Also, use it for a variety of things. Each couple of months, make yourself a little "project" for learning to do some new thing with it -- set up a web server, a file server, a firewall, a print server,
Finally, get yourself a copy of Programming Perl and an account on perlmonks. It is really amazing how useful Perl can be for system administration.
Cut that out, or I will ship you to Norilsk in a box.
Go back in time, and get a copy of the LFS howto/book when it was in its infancy - version 1.1 or so ought to do... Very well documented, but you do it and you learn it.
Don't blame me, I voted for Kodos
I'm a slack user since 7, IIRC.
a d.php?t=530208&highlight=firewall) of just over 100 slackers (not statistically significant but hey) there were slightly more using script generators than writing their own scripts.
>>> "... you have to write your own iptables firewall script."
This simply isn't true. And in my poll (http://www.linuxquestions.org/questions/showthre
I like firestarter (http://www.fs-security.com/) and it seems others do too.
FWIW.
Oh and re the car analogy - having driven a stick shift since 17 at 26 I learnt and passed my test on a full geared motorbike, the first time I got on the fully-automatic twist-and-go scooter I crashed. My first proper crash. This pretty much mirrors my use of "easier" linux distros, which I find harder to use.
Your question is a bit vacuous .... what do you want to achieve?
... which is relied on to install packages - moreover all source packages are tar.gz-ed ... how to reinstall!? [fixed it now btw].
Anyhow, have you tried installing something like dvd::rip (or a LAMP environment or KDE) from scratch - ie download the source code, configure-make-and-compile and fix any problems along the way.
You can consider with dvd::rip you've been successful when you rip a section of dvd with sub-titles and burn it to a CD that runs in your dvd player (or eg for LAMP, you're serving a DB driven site, like a CMS, from your own box).
IIRC dvd::rip gave me problems because at the time decss was hard to find and transcode was a pain to install; it was also my first use of cpan (yeah I wasn't looking for a challenge so I used cpan to install the perl stuff).
---
You could also hang out on a linuxquestions board (me @ Slackware!) and research and solve peoples problems. I had a good one the other day when I accidentally removed the tar package
Understanding The Linux Kernel is a good resource. For more conceptual stuff, Modern Operating Systems is great.
And don't resort to any other operating system to do things unless it's a matter of life and death, or job and no job, or some other such decision which should be easy to make. And get some more machines and just play with the things you want to play with. Set up some competing types of VPN. Set up distcc, with cross compilers if you are on different architectures. Actually accomplishing real tasks will do more to teach you how to solve problems than anything else you can possibly do.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Where is a damn link or book or whatever that explains Linux admin concepts from a Windows perspective? I have been using windows since 3.0 - I know how to admin windows. It has become intuitive and second nature to me. Everytime I give Linux a spin, I end up frustrated and blowing it off. Mostly because I find it incredibly time consuming to relearn simple shit like downloading and installing an app.
Where is the link that tells me: "Windows Way of installing an app - go to website, download latest version, extract and 2x click on setup.exe click next next finish. Linux Way of installing an app - blaa blaa whatthefuckever"
Whoever writes this rosetta stone and promotes it will be the root cause of a lot of people running Linux on their non-gaming boxes.
I fully expected to find a link like this when I clicked on this article, but instead I see crap like - create your own distro - you'll learn it all. Well no fucking shit sherlock, but if running Linux really requires that hefty of a time investment then it won't make serious inroads to the windows marketshare.
Note - this is not a troll (even though I am pissed) - I am seriously asking for help. I have four boxes in my house that I use for music, movies and web browsing that are all running Win2K - conceptually, running Linux on these would be great, but not if it is going to take me hours to figure out how to install a damn app...
I think this is a good indicator of where Linux is at in a lot of ways. It's promising and a great alternative--except that it's still not especially friendly for anyone who isn't an uber-tech. I'd like to run Linux on my desktop and laptop but I get frustrated trying to configure things every time.
part 0:
$ man man
Here is prob the best online resource: http://rute.2038bug.com/index.html.gz - The Rute User's Tutorial and Exposition. IMO, It's every bit as good as anything off the shelf. Have a look at the table of contents and you will see how wide the coverage is. You can also download it in HTML or PDF for local viewing.
There are no magic. The first thing you must to do is to read log file /var/log/messages.
For mail server, read: /var/log/maillog
For Apache server, read: /var/log/httpd/error_log
The best tool to read recent errors is: tail
Use: "tail -f /var/log/messages", to read continouslly that log file, and find errors, so you can correct them.
Do yourself a favor and first learn how operating systems (in general) work. The problem with linux is many people will start off just by saying "run this command that then do this and it will work" but when that's all done you fixed the problem but have no clue on why it worked or what the commands were doing to make it work.
As an unexperienced undergrad CS student, I tried running redhat, mandriva, and even a really simple Freesco floppy distro (router distro), but at the end of the day I was still having a lot of trouble when something went wrong. It wasn't until I took my CS OS course that things really started to make sense.
For example, let's look at the file system works. The file system will typically divide the disk into blocks of equal sizes of say 4096 bytes per a block (in most file systems you can choose a different block size and the default size is different). Obviously there's a problem with this: files typically aren't 4096 bytes in size so if the file is smaller, we wasted space (you can only have one file per a block), or if the file is larger we need some kind of method of allocating and keeping track of which blocks make up a file. All of these details are up to the file system and there are different methods and approaches to accomplishing this (hence why we have different file systems). This also explains why on some file systems, if you create a file that has a really tiny amount of data, it still consumes 4kb of disk space because the file system reserved an entire block to store that data. It also explains why when you go out and buy a hard disk, divide by 1024 to get the actual number of bytes, plug it in and format it, but when you look at the available disk space, it's still lower compared to your original calculation. That's because the file system used up blocks to index your files and when it was done calculating the necessary space it needed, it subtracted those blocks from the disk to show you the actual usable disk space. Some of these parameters and pieces of information vary depending on the file system and OS.
It's really a lot of knowledge and then some if you want to learn something about networking (I had to take another class for that). But once I really understood how computers and OSes worked (not just linux itself), I really felt like I understood what I was doing and I could actually interpret what the commands where telling me. For example, the next time you issue the 'df' command to see how much disk space is free, the default option typically shows the number of free blocks not the amount of free space. Now you know why (and hopefully why the number of free blocks is actually important). If you don't want to take a class, you could probably also get by by buying the same books required by the class and just reading the book, but my TA was actually a BSD guy so he gave us some other insight that you probably wouldn't find in the books. But the main idea is to first understand how the computer and OS work in general, then start reading about the specific commands and details specific to a particular OS.
Linux just isn't like that. Most of the time you don't go off downloading an app to "do something" unless it's like a web browser or office package or something. For most things it's all about configuration of what you have to make services available. Most stuff is installed when you installed the OS in the first place. If not, it's usually a completely managed process.
./configure, make, make install. But that's probably not for you.
Installing apps on Linux is a process that goes something like this:
Prep:
0) Find out how your linux distro of choice installs software. (Is it APT or Synaptic? Yum? Other?)
1) Make sure you can install or update software using that tool. Follow examples on the websites specific to your distro to get used to this.
Getting Software:
1) Find the software that does what you want it to do. Read about people's experiences with it; often there's some choices instead of one defacto thing so you need to research if you don't want to be a guinea pig. This takes some web searching.
2) Check to see if the software is in your distro's repository already. It probably is. Use the tool from the prep-steps to install the software by name.
OR
3) The software might be in an outside repository not supported by your distro. These repositories are your friend because they eliminate the potential configuration management nightmares of trying to support one-off-software and their dependancies on your own. For example, one popular 3rd party repository of software for Fedora is called LIVNA. There are many cool thing in there, and they manage all the little bits that make those cool things work.
4) Follow the instructions on the website for whatever repository to add that to your software installation tool so it can pull stuff from there. As in step 2, you can then just install that software by name.
OR
5) Take a chance, and download an RPM or DEB file from the software page directly. These will probably not install on their own, and require you to install other things to make them work. Or you might get lucky and they work out of the box. Give it a shot.
6)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
When I was first getting into Linux, I picked specific things that I wanted to learn to do, and focused on those. How do I setup a DNS server? RADIUS? DHCP? MySQL? I find it a bit easier if you have a goal set when trying to learn, rather than just trying to "learn more" about the system. During the course of working on these services, you'll learn more about the system. The secret is to not try to do the simplest installation/setup you can do, but the most interesting. Don't just setup RADIUS, setup RADIUS with a MySQL back-end. You'll quickly learn how different parts of different software operate and will get a better grasp of how things work. The basics really are the most fundamental thing to learn, since everything builds on them and most things in Linux are a combination of smaller, simpler tasks. For example, setting up a LAMP server is really, 4 tasks: Linux, Apache, MySQL, PHP. Of course, that's a bit oversimplified, but you get the idea.
The distribution doesn't matter. Your best method is to try as many as you can that are fundamentally different. Don't try Debian and Ubuntu and Knoppix. Try Ubuntu and Red Hat and Gentoo. Use systems that are as different from each other as you can, and you'll start quickly picking up on the differences and the similarities. This is what will make you a coveted administrator, since your skill set will be varied and you'll be well-versed in working in unfamiliar territory and good at resolving issues where you don't already know the answer. Also, definitely look into learning bash, and probably perl, too. You don't need to be an expert on them, but you'll definitely want to be familiar with them and be comfortable with them if you ever decide to become a Linux Administrator.
I hope this helps and welcome to the wonderful world of Linux.
I have to correct myself. upstart does indeed replace init. That doesn't invalidate my suggestion, though, it just changes it. On Ubuntu the thing to do is to dig through your upstart configuration file and the scripts that it runs. There's still no magic, and you can still use it as the starting point to understand how everything on your system fits together.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Firestarter? Umm... Ok, my bad, I didn't know about that. I ended up writing my own...
Well...
Still, you have to admit, it's not bad experience to write your own script... Um... Hey, look, over there! Is that free pizza?
(hides)
NO CARRIER
http://www.linux-tutorial.info/index.php/
Dry
O'Reilly Books
"Understanding the Linux Kernel" == A thousand pages about just the kernel.
http://www.oreilly.com/catalog/understandlk/#top
The only thing new in this world is the history that you don't know.[Harry Truman]
/etc contains all the settings /etc/init.d is like services
/var/log contains all your logs about various things
In the bootmanager if you add s to the list of parameters this is like your Windows safe mode (Single user mode).
Running dmesg will show you what was happening at bootup.
Free pizza ... where!?
Oh and I'd probably have written the script too if I could understand it all without having to read the flippin' man pages.
Ugghh.... The man pages... Boy, did THAT take a long time. I was reading docs from all over the place, from security faqs to howtos to man pages...
:)
What an ordeal. But it was kinda fun. And I like my script!
NO CARRIER
Ubuntu example:
- Run synaptic (or kpackage or adept or whatthefuckever, but synaptic seems easiest to me). If this is your first time running synaptic, you may want to visit the "Settings" menu and activate some of the deactivated repositories, or add new ones if you know what you're doing. After changing the repositories, click "Reload package information" in the "Edit" menu.
- Then use the "Search" button or dig through the categories in the sidebar to find the packages you need, and mark them for installation. If any of the packages depends on additional packages to function (e.g. libraries), a dialogue box will pop up, list them, and ask you for permission to install those as well.
- Click the "Apply" button. The packages will be downloaded and installed automatically. Most likely, you will not be asked any questions (where to install them, who to install them for, etc.). If nothing seems to happen, though, click "details".
- Exit synaptic. You can now start your new apps by typing their name (no PATH tweakery necessary). Usually, they've also been added to the "start menu" equivalent of your desktop environment.
If you already know the name of the package, you can just type- sudo apt-get install packagename
To uninstall:- sudo apt-get remove packagename
(Or use synaptic again.)Other distributions are similar.
Sometimes, though, there's no ready-made package in any of the repositories, and you'll indeed have to download something from a website.
It may be ready-to-run (just extract it and copy it wherever you want), it may have a very Windows-like installer script, or you may have to bite the bullet and compile it from source.
Allegedly, compiling from source is as easy as typing "./configure", then "make", then (with superuser privileges) "make install" in the source directory, but I've found that it tends to require additional packages so some time may be spent on this.
System Components:
.debs manually or .rpms with alien. .debs manually or .rpms with alien.
./configure;make; test the app, edit some config files and make install.
Windows: Start->Control Panel->Add/Remove Programs
Ubuntu: System->Administration->Synaptic Package Manager
Debian: $dselect
(Open)Suse: yast2
Commonly used packages:
Windows: Download package from some site (possibly Sourceforge, possibly some spyware ridden godawful adsite) unzip/execute and follow prompts to install.
Ubuntu: System->Administration->Synaptic Package Manager; with possible alternative of downloading and using
Debian: $dselect; with possible alternative of downloading and using
(Open)Suse: yast2
Typical Bleeding Edge Software installs:
Windows: Double Click Zip file, hunt and peck for a README, extract to a location, run an AV or two against any executables and double click while crossing fingers. Find ini/registry import and manually hack it till you get it right.
*Nix: tar -zxvf $tarball.tar.gz; cd $tarball... Hunt and peck for README...run
I'm sure there's a fedora/rhe easy way as well, but I haven't used them seriously in over 4 years.
On a side note, this shit ain't as hard as it used to be; you probably haven't tried Ubuntu/Knoppix et al in years.
Only time I've had to go to command line at all is for installing custom BS that most won't be doing anyways. I spend more time in the Registry and in a CMD shell at work than I do in a bash shell on my fully driver supported Ubuntu lappy.
The Debian Policy Manual codifies the whys and hows of basic unix operation. Some of it is debian-specific, but debian is a pretty big chunk of "the world of linux" and their policy manual reflects a whole bunch of that common / shared knowledge. What goes in "/var"? How to be sane with "/etc/foo" v. "~/.foo/"? Cron + Init. Basically if a package does something "not in the debian way", then their policy documentation is designed to be able to point to a section and say: "we'd really prefer something like the following..."
It's a great resource. Also if you really feel like a challenge, grab an older version of debian and do an install. I thought I knew my PC until it blew up back in '99 and I (being tired of windows) installed debian. And proceeded to have to take out every piece of hardware (including memory sticks and floppy drives), putting them back in one by one until I could figure out what was causing XYZ to work or not work. Good times, and you learn a lot.
--Robert
Gentoo.org
Linux for Windows Administrators (Mark Minasi) may be what you're looking for.- Mark-Minasi/dp/0782141196/ref=sr_1_3/701-7362000-3 966705?ie=UTF8&s=books&qid=1177438579&sr=8-3
http://www.amazon.ca/Linux-Windows-Administrators
or http://tinyurl.com/3b8ug8
Your complaints are very similar to my own and it's the reason I keep giving up on Linux. I know Windows so well that it is extremely frustrating when a simple problem pops up in Linux that is very complicated to fix but could be fixed within seconds on Windows. I realize that's not necessarily Linux's fault but that still doesn't ease the frustrations. I recently bought this book (have yet to read it though) but am hoping it will come in handy, especially now that I am giving Linux another chance and have just installed Ubuntu. The book focuses on Redhat but I am hoping that it will translate well enough that it will still be usable on Ubuntu.
Two of the best resources out there are: IBM Developerworks LPI certification preparation material: http://www-128.ibm.com/developerworks/linux/lpi/ VCampus preparation material: http://www.vcampus.com/lpinama