In opera, there's a nifty feature that lets you search the net by using the address bar. For isntance:


code:--------------------------------------------------------------------------------
Address bar: g linux
--------------------------------------------------------------------------------

will search linux in google

now edit the .opera/search.ini file and add these two:


code:--------------------------------------------------------------------------------
[Search Engine 2]
Name=&Freshmeat
URL=http://www.freshmeat.net/search?q=%s§ion=projects&x=0&y=0
Query=
Key=f
Is post=0
Has endseparator=0
Encoding=utf-8
Search Type=0
Verbtext=17063
Position=-1
Nameid=0

[Search Engine 3]
Name=Google Linu&x
URL=http://www.google.com/linux?q=%s&sourceid=opera&num=%i&ie=utf-8&oe=utf-8
Query=
Key=x
Is post=0
Has endseparator=0
Encoding=windows-1251
Search Type=1
Verbtext=17063
Position=-1
Nameid=0
--------------------------------------------------------------------------------


as you can see, now if you do "x linux" or "f linux", it will search linux in google/linux or freshmeat.

Ctrl-X then ~ Lists all the users on the system
Ctrl-X then / Lists all files in the current directory
Ctrl-X then ! Lists all files in /usr/bin

Ctrl-X then @
Gives me "localhost localhost.localdomain"

If you want to save the output of a command into a text file, you use >. An example to redirect the output of ls to foo.txt:
ls > foo.txt
IMPORTANT: If there is no file called foo.txt, it will be created - without a warning.
If, however, there akready is a file called foo.txt, it will be overwritten - also without a warning. This means the date which it contained at first will be lost.

Next we have the >> redirector, which does exactly the same as >, except that it appends a file. For those who aren't familiar with English, this means that in case foo.txt already exists, the data it contains won't be overwritten - the new data will just be added ('appended') to the end of foo.txt

As some might know, not all data which an application outputs into a terminal (or a text file) is output (aka stdout, or standard output), there are also error messages (aka stderr). To redirect the error messages to a file errormsgs.txt, you use 2>, like this:
appname 2> errormsgs.txt
The 2> redirector can be very useful if you're having a problem with an application: you start it up from a terminal like this:
buggy_application_name_goes_here 2> /tmp/error.log
and afterwards you include /tmp/error.log in a mail to the application's mailinglist/developer.
IMPORTANT: this will just redirect stderr, not stdout.

When you want to report information about a program which isn't behaving correctly like the above example, you'll probably want to redirect the normal output, too.
You can achieve this with 2>& redirector. So a better version of the error-reporting command line above would be this:
buggy_application_name_goes_here 2>& /tmp/error.log

So now you can redirect stdout and stderr... what's left? standard input, of course.
You can redirect input from a file using <.
How can this be useful? Well, let's take the first example again:
ls > foo.txt
This just redirects the output from the command ls to foo.txt, but what if we wanted to sort it using the command sort?
Well if you read this topic, you know how you can pipeline the data, like this:
ls | sort > foo.txt
Another possibility, is this one:
ls > foo.txt
sort < foo.txt > sorted_foo.txt
In this case, using the < redirector would be pretty dumb of course, since it would change a one-liner to two lines of code, and IMHO the second command is less clear.
However, I think you now understand how < works, which is the most important. The truth is I just don't know a useful way to use < at the moment - I've never used it even

a quick way to see what services are open via inetd on your machine.

grep -v ^# /etc/inetd.conf

It displays all lines not starting with a comment. Usefull for other things as well I'm sure.

Copied From Another Source
=======================
How to build a Linux kernel:

One of the more complex tasks that many Linux users will have to face is compiling a custom kernel. This is often done to add features that were not enabled in the kernel that came with the distro, or to disable unneeded or unwanted features that were. It's also the only way to take advantage of experimental code, unofficial patches, and other things that you might want.

This procedure will tell you how to compile a kernel with the Preemptibility patch added. This patch will decrease latency quite a bit, which is good if you plan to do multimedia stuff like playing 3D games, rendering, video editing, and the like. The latest stable kernel at the time this was written, and thus the one that will be used in the example, is 2.4.18.

How it's done:

1. Download the kernel source.
2. Download the preempt-kernel and lock-break patches.
3. Open a shell.
4. Become root. su and enter root password when asked.
5. Move all of the files you downloaded in steps 1 and 2 to /usr/src. mv linux-2.4.18.tar.bz2 *.patch /usr/src
6. Enter the /usr/src directory. cd /usr/src
7. Check if there is a linux directory placed here by your distro. ls linux
If there is, you might need to re-arrange your include directories. See the bottom of the FAQ for info on how this is done, then come back here.
8. Unpack the new source. tar xjvf linux-2.4.18.tar.bz2
If you get an error about j not being a supported option, replace it with y.
9. Apply the patches. patch -p0 < preempt-kernel-rml-2.4.18-4.patch && patch -p0 < lock-break-rml-2.4.18-1.patch
10. Enter the Linux source directory. cd linux
11. Configure the kernel. This is the long and difficult part of the process. If you want to use the graphical config program, run make xconfig. If you want to use the non-graphical config program, run make menuconfig. I don't think that either one is better than the other, it's a matter of personal taste. If you like your arrow keys, use menuconfig. If you like your mouse, use xconfig.

Either way, you'll be presented with a menu, with a list of submenus, many of which have submenus of their own. Just go through each one, enabling support for hardware you have and features you want. Most options have detailed descriptions available, just use the help button.

Also note that many features can be built as modules. If you want to be able to disable and enable a feature at will while the OS is running, hit M.

12. Once you have completed your configuration, it's time to actually compile the kernel. time make dep modules modules_install bzImage
13. Now, copy the bzImage file (the kernel itself) somewhere meaningful. cp arch/i386/boot/bzImage /boot/mykernel
14. You must now set up your bootloader. Every bootloader does this differently, but since LILO is probably the most common, I will give instructions for it:
1. Open /etc/lilo.conf in a text editor. kedit /etc/lilo.conf
2. Locate the chunk beginning with image = whose label matches the boot menu entry you normally select to boot Linux. Copy it and paste it at te end of the file
3. Change the image = line to image = /boot/mykernel and change the label to something else. It can be almost anything, but it can not contain spaces.
4. Save and exit.
5. Update to boot sector. lilo
15. Your new kernel is now built and installed. Reboot and select the entry you just created to boot your new kernel.
16. If all goes well, you're done. If not, go back over your kernel config and make absolutely certain that everything is correct. Then repeat steps 12 and 13, then run lilo again.

Congrats, you're now running your own custom kernel!


If your distro included a /usr/src/linux directory
Many distros seem to symlink the /usr/include/linux and /usr/include/asm directories to locations in /usr/src/linux. This makes the kernel compilation process a bit more difficult, since you can't build it in the /usr/src/linux directory. To fix this:

1. Check to see if the include directories are indeed symlinks. ls -l /usr/include/asm
If the result line ends like asm -> /usr/src/linux/include/asm you've got symlinks, so read on to fix this. If it just says asm or /usr/include/asm, it's properly set up and you don't need to change anything, so go to step 7.
2. Remove the symlinks. rm /usr/include/asm /usr/include/linux
3. Make proper directories in their place. mkdir /usr/include/asm /usr/include/linux
4. Copy the asm headers. cp -R /usr/src/linux/include/asm/* /usr/include/asm
5. Copy the linux headers. cp -R /usr/src/linux/include/linux/* /usr/include/linux
6. Make a autoconf.h file. touch /usr/include/linux/autoconf.h
7. Delete the old linux source, it is no longer needed. rm -rf linux
8. Go back to the kernel build instructions above.

Can I run Windows software on UNIX?


--------------------------------------------------------------------------------
As strange as it sounds, yes. You can run SOME Windows software on UNIX systems using WINE.

WINE is a recursive acronym that means "WINE Is Not an Emulator", but it could easily mean "Windows Is Nearly Exinct". It runs on Linux, FreeBSD, and Solaris, and possibly some other *NIX variants too. It is a free implementation of the Win32 API that, among other things, lets you run Windows software on *NIX.

There are several independantly maintained "forks" of WINE, in addition to the "official" tree maintained by WINE Headquarters. The most popular fork, even more popular than the official tree, is WineX, a gaming-centric fork maintained by Transgaming Technologies. This fork has the distinct advantage of DirectX 8.0 support, allowing you to play many recent Windows games. I use WineX, so the instructions in this FAQ will be based on it, but most, if not all, of it should work just fine with the official tree, which will be referred to throughout this FAQ as WineHQ.

Before you can use WINE, you need to install it. Binary releases (RPMs, apt-gettable packages, ports, etc) are available, but are often outdated. If your distro comes with a WINE package, don't install it, or if you already did, remove it. By following this FAQ, you will be getting the WINE source code from a CVS server, and compiling it yourself.


You must now decide if you want the WineHQ or WineX version.
NOTE: In the commands below, wherever it says : pserver: below, remove the space between the colon (: ) and pserver. I had to add the space to keep the forum from screwing it up.

To get the WineHQ source:

1. Open a shell window.
2. cvs -d : pserver:cvs@cvs.winehq.com:/home/wine login
3. You will be asked for the password. It is cvs
4. cvs -z3 -d : pserver:cvs@cvs.winehq.com:/home/wine co wine


Or, to get the WineX source:

1. Go to Transgaming's Site and read the licence.
2. Open a shell window.
3. cvs -d : pserver:anonymous@cvs.winex.sourceforge.net:/cvsroot/winex login
4. You will be asked for the password. Just hit enter.
5. cvs -z3 -d : pserver:anonymous@cvs.winex.sourceforge.net:/cvsroot/winex co -r winex-2-0-branch wine


Either way, the last command will begin the download. It will take a few minutes. When it is done, you will have the source code in the wine subdirectory of wherever you were when you ran the above commands. You will need to compile and install it next.

While still in the shell window:

1. Become root. su and enter your root password when asked.
2. cd wine
3. tools/wineinstall
4. It will take a long time for WINE to compile, so go do something productive.
5. When it is done compiling, it will ask a few questions. If I recall correctly, they are all yes/no questions, and you should answer 'yes' to all of them. If the setup program asks for a "fake windows root" directory, it will offer a default setting of /c. Accept that.
6. Open /etc/ld.so.conf in a text editor. If there is a /usr/local/lib line in it, no changes need to be made. If there isn't, add it.
7. ldconfig
8. chmod -R 777 /c
8.5. Optional for better performance, but a very serious security risk: chmod 777 /dev/mem
9. exit
10. cd ~
11. su and enter root password when asked.
12. chown -R (your username) .wine
13. exit
14. which wine
If it says /usr/local/bin/wine you're all set. If it says No wine found in {big list of directories} then do export PATH=$PATH:/usr/local/bin


Now WINE is installed, but you still have to do some additional configuration before you can run all of your favorite Windows apps.

1. Open ~/.wine/config in a text editor.
2. The first few stanzas define the drive letters that your Windows software will see. Make sure the Floppy and CD-ROM sections point to the proper locations.
3. Now scroll down to the x11drv section. Here you will find options that control the appearance of Windows apps. The following settings are good to know:
PerfectGraphics: The performance hit isn't that bad, and has no effect on games. Set this to Y.
Managed: This makes Windows apps behave more like proper X client apps. I set this to N, and run WINE with the --managed switch when starting an app I want to use like this.
Desktop: When this is uncommented, Windows apps will be confined to a window whose demensions are specified here. Some games won't work if this is enabled, some won't work if it isn't enabled. This is one of the many things to play with if a program doesn't work at first. Put a semicolon (; ) in front of this line to disable it, and remove the semicolon to enable it.
DesktopDoubleBuffered: Set this to Y.
4. Save the file and exit the editor.

It is now time to give things a little test.

1. Find a simple Windows app, such as Notepad, or SkiFree, or something like that.
2. Put it in the /c directory.
3. cd /c
4. wine ./appname.exe
5. If all has gone well, you will see some font-related stuff scroll by for awhile, and then the app will appear. If it doesn't, chances are you got some bad source code. Uninstall WINE and try again...

If all went well with that test, it's time to put WINE to some serious use. Try installing Microsoft Office, or your favorite Windows game. Keep in mind that very few games work perfectly, and most don't work at all.


WINE must be run from a command line. The basic structure of the command is:

wine --wine --switches -- ./appname.exe -app -switches

The final -- before the ./appname.exe tells WINE that the switches that follow are for the Windows app, not WINE. For example:

wine --debugmsg -all -- ./MaxPayne.exe -developer

The above will tell WINE not to show any debugging messages, and to pass the -developer switch to the app (Max Payne in this case. It enables the console, allowing entry of cheat commands! )

Omitting the --, however, will have fatal consequences:

wine --debugmsg -all ./MaxPayne.exe -developer

The above would produce an error, since WINE doesn't understand the -developer switch.

Introduction to Cygwin


--------------------------------------------------------------------------------
Cygwin is a UNIX-compatible environment that runs on Windows systems. It consists of cygwin1.dll, a library that takes POSIX calls and translates them into Win32 calls (kinda like winelib in reverse); a shell (GNU BASH, the shell used on most Linux systems, is the default); an implementation of the X Window System and, of course, GCC.

There are many reasons why you'd want to use Cygwin:
1. You are used to UNIX-like systems, but are forced to use Windows for some reason.
2. You want to compile and run *NIX software on Windows.
3. You are thinking of switching from Windows to a UNIX-like OS, and want to learn more about the environment you will be working in, before you actually do it.
4. You need an X server on Windows, and don't want to pay upwards of US$600 for one.

This FAQ will tell you how to set up Cygwin, and some of the cool things you can do with it. Please note that these instructions assume you are using Windows NT/2000/XP. The procedures are similar for Win9x, use common sense.

Installing Cygwin
1. Login as Administrator, or some user with Administrator priviledges.
2. Go to Cygwin.com
3. Click Install Cygwin Now to download setup.exe. Make a directory "cygwin" and put setup.exe there.
4. Run setup.exe
5. Choose "Install from Internet". You will get a dialog asking where you want to install Cygwin, who to install it for, and the default text file mode. Accept the defaults. You will then be asked about proxy settings, and then you willl get a list of mirror sites. If you know which site is closest to you, use that one. If not, pick one at random and hope for the best.
6. You will then get a list of packages. There are tons of them, but almost all of them have descriptions. Installing everything is a safe bet if you haven't the slightest idea what this is all about.
7. Cygwin will install itself, and then ask if you want any shortcuts. Installation is complete.
8. If you get any warnings about incomplete downloads, click "retry", pick a different mirror, and then just hit "next" on the package selection screen. If it fails again, don't retry, cygwin should work just fine without it.

Now you've got a Cygwin shortcut somewhere in your start menu or desktop. When you start it, you will get a command prompt. The command prompt proto-FAQ written earlier can give you an idea of what to do here. There are a few things you should know about cygwin's filesystem:

1. / is actually C:\cygwin, or wherever you installed cygwin.
2. You can access the rest of your drive(s) from the /cygdrive/letter directory. For example, C:\ is /cygdrive/c, D:\ is /cygdrive/d, and so on.
3. /proc and /dev are present, but they aren't all that useful, since Windows just doesn't like the "everything is a file" way of doing things.
4. Cygwin interprets .lnk files (shortcuts) as symlinks. This is Cygwin's way of getting around NTFS's serious lack of POSIX-mandated features, such as symlinking.
5. Everything is case sensitive. Do not forget this.

Now, here's a few things you might want to do to get the most out of Cygwin:

Setting up X
No nVidia drivers this time around, but you DO have to reconfigure your environment a bit to make X work. In the interest of modular design, cygwin doesn't do this for you, as that would mean assuming X is installed. That is unacceptable.

Note that all of these steps are to be performed in the Cygwin shell.

1. vim /etc/profile
2. Find the PATH line. Add /usr/X11R6/bin to it. Then save and exit.
3. export PATH=$PATH:/usr/X11R6/bin (to make it take effect in the current session)
4. man XWin
5. Look over the command-line switches in the manpage. Decide which ones you will want to start X with.
6. vim /usr/X11R6/bin/startxwin.sh (In cygwin, startxwin.sh is the best way to start X. The more UNIX-like "startx" command also works, but not very well.)
7. Find the XWin command in this script. Add the switches you decided on in 5. Also note the twm command. You will be changing that to the window manager you want when you get everything set up. Save and exit.
8. /usr/X11R6/bin/startxwin.sh
9. If all is well, a window with a stippled background (the infamous monitor- and head-exploding X stipple) and a command prompt window (an xterm) will open. This is your X server in all it's glory. If you set it to run fullscreen, then this display will cover your entire screen, instead of showing up as a window. You can get out of it with ALT-F4 (the windows way) or CTRL-ALT-BACKSPACE (the *NIX way).
10. At this point you might want to consider getting a more feature-rich window manager to take the place of TWM. WindowMaker and FVWM are inclued with Cygwin as optional packages. Almost any window manager should compile and run without much hassle. KDE 2.2 is available as well if you want that. Either way, when/if you install a new window manager, just open up /usr/X11R6/bin/startxwin.sh and find the twm command, and replace it with the command to run your window manager.


Making it possible to run Cygwin apps from normal command prompts and the windows GUI

Windows NT:
1. My Computer > Properties
2. Advanced tab
3. Environment variables button
4. Find the "PATH" one. Add C:\cygwin\bin to it.

Windows 9x:
1. Open c:\autoexec.bat (when was the last time you heard someone say THAT? )
2. Find the PATH line. Add C:\cygwin\bin to it.
3. Reboot.

Here's some for the OS X users out there(hey, a Mac is still a *nix box in this case).

Q: How do I open an application/file/folder from the terminal in OS X?
A: OS X includes a special command to do this. The "open" command will simulate a double click on any file/folder, allowing you to open them from the terminal. Just type "open <item's name>" to open it. Ex: to open the calculator, I could type "open /Applications/Calculator.app", which would open the Calculator no matter where I am in the file hiarcy. If I were already in the Applications folder, I could use "open Calculator.app". Please note that the vast majority of OS X applications are so-called "packages", which have .app on the end, and while not visable from the Finder directly, .app is needed with the "open" command. Also of note that when opening Applications with this command, they may not always open and generate errors instead. Running "open" as root usually solves this problem.


Q: How do I enable the root user in OS X?
A: The root user is "disabled" by default, and needs to be enabled if a user wants to gain full root access(although 99% of the tasks you need to do can be done through sudo, so enabling root isn't reccomended). To do this, you need to first open the NetInfo Manager in /Applications/Utilities. Once it's opened, go to the "domain" menu, then to "security - authenticate". From there, enter the username and password of a user with admin access. Once that's done, go to "domain - security" again, and click on "enable root user". After you do that, OS X will pop up a warning saying that root doesn't have a password, at which point you'll need to assign a password to root, and confirm it. After this, the root user will be enabled, and can be disabled in a similar mannor.

Introduction to running apps remotely with *NIX


--------------------------------------------------------------------------------

Since the very beginning, UNIX and related OS's were designed to be used by remote terminals, rather than a keyboard and display device connected directly to the system. Although nowadays most people control their *NIX systems with a keyboard, monitor, and possibly a mouse connected directly to the system, you can still do almost anything remotely that you can do locally.

Throughout this guide, the term 'Local System' will mean the computer you are sitting at, and 'Remote System' will mean the server that the applications are being run on.

If you want to run applications over your network, there are a few different programs that you will most likely use. Here's a description of them:

ssh: secure shell. Using an SSH server on the remote system, and an SSH client on the local system, you can log into and get a command prompt from the remote system. You can do anything at this prompt that you could at a command prompt on the remote system's screen.
The X Window System: This is a suite of programs that provide a graphics infrastrucure for *NIX. It consists of an X server, which creates a framebuffer for graphical apps, and X clients, software that uses the X server to display a graphical interface. When the X server is run on the local system and the X clients are run on the remote system, you've got remote X.

Running command-line apps remotely is trivial, to say the least. Just log in to your remote system with SSH and do it. If your local system runs *NIX, you almost cerainly have the OpenSSH client. To use it:

ssh username@name.or.ip.of.server

You'll be asked for your password. Enter it, and you will be logged in. If you're running Windows, and don't have Cygwin, you'll need an SSH client. I recommend PuTTY. Just download, unzip, and then run PuTTY.exe. The default options are fine, but if you know what you're doing, feel free to tweak it to whatever extent you want to. Just enter your remote system's name or IP, select SSH, and click Connect. Enter your username and password when asked, and you're in.

Running GUI apps is less trivial, as you need to set up remote X. There are a few ways to do this, such as setting up an SSH tunnel, and some simpler methods. What I will describe is a very simple method, which is not secure, and won't work through a router. The X client on the remote system will connect directly to the X server on the local system, with no tunneling.

You need an X server running on the local system. If you're using *NIX, I'll assume you have and are running X, since you almost certainly are. If you're using Windows, you will need to obtain and set up an X server. I recommend the one included in Cygwin. Anyway, here's how to do it:

1. Open up a local command prompt.
2. xhost + ip.of.remote.system
3. SSH into the remote system.
4. export DISPLAY="ip.of.local.system"
5. Run your graphical app. If all is well, you will see the app on the local screen.

There is also another method for remote GUIs, that is probably a lot easier to set up and use: VNC. Now, I'm sure that you've all heard of VNC in the past, and maybe even used it on Windows, but it's a bit different on *NIX. Instead of sharing the remote system's screen, it creates virtual screens of arbitrary size and color depth. I strongly recommend you use TightVNC, as it has quite a few more features and uses less bandwidth. Here's how to set it up:

1. Download and unpack the source code.
2. Follow the instructions in README to install it. Make sure you compile and install Xvnc, since there are some extra steps you need to do to get it.
3. Once it is installed, run the VNC server. To get a virtual 1024x768 desktop, run:
vncserver -geometry 1024x768 -depth 24
It will tell you what the display number of the VNC server is. You will need this number to use it. If you're not running X when you start VNC, it will probably be :0, if you are, it will probably be :1. the first time you run it, it will ask for a password. Enter one you can remember.

You can now use any VNC client, either for Windows or *NIX, to connect to it. Just start the client, then connect to ip.of.server:display#. You will be asked for your password, enter the one you gave when you started the VNC server. If all goes well, you will now get a window with the virtual desktop on it. Open an xterm, and run this:

export DISPLAY="127.0.0.1:display# of vnc server"

Then run whatever graphical apps you want to use, and they will pop up on the VNC display.

I hope this has been informative.

Mounting ISO files, encrypting hard drives, and other applications of the Linux Loopback Device

One of the most useful features of Linux is the Loopback device. This is a function of the Linux kernel that lets you do things like mount ISO files without burning it to a CD,
create an encrypted filesystem, hide a filesystem with steganography, create initialization RAM disks for boot CDs and floppies, and much, much more. This FAQ will tell you
how to use it.

There are two ways to create a loopback device. The simplest is using mount with the -o loop switch, and more complex things can be done with losetup.
The former just lets you mount a filesystem that resides within a normal file, such as an ISO, whereas the latter lets you do things like encryption.

In this FAQ, I will tell you how to do three things using the loopback device:
1. Mount an ISO file without burning it to a CD
2. Create a simple filesystem within a file
3. Create a simple encrypted hard drive partition

First, however, you need to have loopback support in the kernel. The kernels included in almost every distro out there either have support built in, or available as a module. If
you get errors when trying the commands below, try running modprobe loop as root. If that produces an error, you will most likely need to compile a new kernel. Whilst
going through the configuration options, ensure that you enable "Loopback Device Support" in the Block Devices section.

Another thing you might want to recompile your kernel for is to apply the crypto patch. In addition to other things, this allows you to use far stronger encryption methods on
the loopback device. If I understand correctly, the best you can do without it is XOR encryption, which is easier to crack than an egg. I will elaborate on this at the end of the
FAQ.

Now, with that out of the way, on to the application examples.


Mounting an ISO without buring it to a CD

This is, by far, the thing I miss most when I am forced to use windows. With a single command, you can mount an ISO file directly off of the hard drive, as if it were a CD.
The command to do this is:

mount -o loop -t iso9660 filename /mnt/cdrom

Explanation:

mount: Involks the mount command.
-o loop: Specifies that the option "loop" be passed to mount. This tells it to attach the specified file to a loopback device, and the mount that automaticly.
-t iso9660: Specifies that the ISO-9660 filesystem is being used. mount can detect this by itself, but I always specify it anyway.
filename: This tells mount what file to mount.
/mnt/cdrom: The mount point that will be used. This can be any directory. /mnt/cdrom and /cdrom are considered the standard places to mount CDs, so that's what I
use.

When you are done with it, unmount it using this command:

umount -d /mnt/cdrom

Explanation:

umount: Involks the umount command.
-d: Tells umount to free the loopback device. You can omit this, but the loopback device that was used will remain bound to the file.
/mnt/cdrom: The mount point you used.

Note that this is not limited to ISO files, you can use this procedure for any filesystem embedded in a file, just substitute iso9660 with the correct filesystem. More information
on that in the next example.


Creating a filesystem within a file

There are many reasons why you may want to create a filesystem within a file. Maybe you want seperate filesystems for /home, /usr, /var, and so on without messing
around with setting up partitions. Maybe you want to create a RAM disk for a boot floppy or CD. Maybe you want to test a filesystem utility you're writing. That does not
matter. Regardless of why you're doing it, it is a pretty easy thing to do. Here's the procedure:

1. Create a blank file of the needed size using dd:
dd if=/dev/zero of=filename bs=1M count=size

Explanation:

dd: Runs the dd command.
if=/dev/zero: Tells dd that the data source is /dev/zero, which is a "device" that just spits out zeroes.
of=filename: Tells dd to create a file called filename.
bs=1M: Tells dd to create the file in 1 MB blocks. This can be anything, but using a value like this makes it easier to figure out what to specify for count=.
count=size: Tells dd to copy size blocks, whose size is specified in the bs= parameter.

Example for a 800 megabyte file called loopfile: dd if=/dev/zero of=loopfile bs=1M count=800

2. Create a filesystem in the file. The command varies widely based on what filesystem you use, but most are of the format mkfs_tool_name filename. Here's an
example for Ext3:

mke2fs -j filename

Explanation:

mke2fs: Runs mke2fs, the program that creates ext2 and ext3 filesystems.
-j: Stands for journal. Tells mke2fs to make an ext3 filesystem.
filename: The name of the file you made with dd in step 1.

3. Mount the filesystem. The command for this is exactly the same as the one used to mount an ISO file as explained above, except you replace iso9660 with the type
of filesystem you created in step 2. The same is true for unmounting.


Encrypting a hard drive partition

This is where you can see just how useful the loopback device can be. Using a fairly simple series of commands, you can create an encrypted volume to store your
pr0^H^H^Hfinancial records and other sensitive material. Note that it does not have to be a hard drive partition, you can make a blank file with dd and use that if you want
to, but it seems to me that a seperate hard drive partition is better for this. Anyway, here's how to do it:

1. Make a blank partition if you haven't done so already.
2. Use losetup to bind the partition to a loopback device with encryption. Depending on what kind of crypto you want to use, and any other options you might want to use,
this command varies, but here's an example:

losetup -e xor /dev/loop0 /dev/sda1

Explanation:

losetup: Runs losetup, the program that controls loopback devices.
-e xor: Tells it to use XOR encryption.
/dev/loop0: Tells it what loopback device to use. There are 8 you can use, ranging from loop0 to loop7.
/dev/sda1: Tells it that the data is to be stored on the first partition of the first SCSI hard drive. Replace this with the device or file the data will reside upon.

When you run this, you will be asked for a password.

3. From now on, just use /dev/loop0 where you would normally use /dev/sda1 (or whatever you used), as it works just like a normal hard drive partition.
4. When you are done with it, run losetup -d /dev/loop0 to detatch it. When you need to access it again, just repeat step 2.


Note, however, that XOR encryption isn't very tough. As I said at the beginning of this FAQ, to get stronger encryption methods, such as twofish and aes, you need the
crypto patch for the kernel, and you also need a patched version of losetup from the util-linux package. Here's how to set that up:

1. Download the crypto patch. It is called "patch-int-kernelversion.patchversion.bz2" and can be found at any kernel.org mirror, in the /pub/linux/kernel/people/hvr/testing directory. At the time of writing, the latest one is patch-int-2.4.19.2.bz2.
2. Switch to your kernel source directory. This source must be clean to apply the patch, so run make mrproper. Note that this will delete your .config, so put it somewhere safe, like /usr/src or your home directory.
3. Apply the patch. This command assumes that you downloaded the bzip2 compressed patch, and it is in the directory above the source directory. bzcat ../patch-int-2.4.19-2.bz2 | patch -p1
4. Copy your .config back into the kernel source directory, and then run your favorite kernel configurator.
5. Enable CryptoAPI support, all the message digest algorithims, any ciphers you want (No harm in enabling all of them), and Loop crypto support (under crypto devices).
6. Before you run make dep, you need to apply the cryptoloop patch. It can be found in the same place as the crypto patch, and is named "cryptoloop-version.tar.bz2". Latest as of time of writing is cryptoloop-0.0.1-pre1.tar.bz2. Download and extract it, then enter its directory.
7. Patch the kernel. make patch-kernel KDIR=/kernel/source/directory LOOP=jari
8. Switch back to the kernel directory, and then compile and install it as normal.

You now have a kernel with CryptoAPI. However, as the README indicates, you need a patched losetup utility to take full advantage of it. Here's how to get that:

1. Download the util-linux source code if you don't already have it. It can be found at any kernel.org mirror, in the /pub/linux/utils/util-linux directory. The filename is "util-linux-version.tar.bz2". Latest at time of writing is util-linux-2.11w.tar.bz2. Save it somewhere and unpack it.
2. Download the patch. It too can be found at any kernel.org mirror, in the /pub/linux/kernel/people/hvr/util-linux-patch-int directory. Filename is "util-linux-version.patch.bz2". Get the one whose version is closest to the util-linux package you downloaded.
3. Switch to the util-linux source code directory, and apply the patch. Assuming the patch is in the directory above the util-linux source, the command is: bzcat ../util-linux-2.11r.patch.bz2 | patch -p1
4. Compile it. ./configure && make
5. Install losetup and its man page. cp mount/losetup /sbin/losetup && chown root.root /sbin/losetup && cp mount/losetup.8 /usr/man/man8/losetup.8

Getting help:
man command - Almost always shows you the manual for the specified program. When told to 'RTFM', this is what you must do.
man -k word - Kind of like a search engine for man.

Moving around the file system:
Navigating the Unix file system is very similar to DOS. Some of the commands are a little different, but they generally behave the same.
cd dirname - Changes to the specified directory.
cd .. - Changes to the parent of the current directory.
pwd - Prints the current directory. Usefull if, for whatever reason, your prompt doesn't give this info.
ls - Directory listing. use the -lh switch to get a detailed listing. Use the -a switch to show hidden files.

Archives:
tar xzf file.tar.gz - Unpack a .tar.gz file. Doesn't work in all systems. I believe this is a feature of GNU tar and the tar on Solaris will not have this functionality. Use gtar if you want this feature. BSD's tar should have this functionality also.
tar xf file.tar - Unpack an uncompressed .tar file.
gunzip file.gz - Uncompress any .gz file, tar or otherwise. If the file you are decompressing is a .tar.gz, it will not be unpacked, it will simply become a normal .tar file.
uncompress file.Z - Uncompress any standard .Z (compressed using the compress command) file.
bunzip2 file.bz2 - Uncompress any .bz2 file.
tar cf file.tar dirname - Put the contents of a directory into a .tar file.
gzip file - GZip compress a file.
bzip2 file - BZip2 compress a file. This is a pretty good compression method, it would be the suggested method if it was more standard on various Unix and Unix-like systems.

Viewing and editing files:
cat - Outputs the contents of a text file to stdout. Only useful on small files or simple manipulation.
more - A somewhat simple text file reader. The SPACE bar moves you one page forward, the ENTER key moves you one line forward, and many times the "b" key will move you one page backwards.
vi file - A really nice text editor, albeit a bit tricky to use.

Environment variables:
PATH - Tells the shell where to look for programs if you don't tell it exactly where it is. It works like the DOS PATH variable, but with colons ( instead of semicolons ( to seperate the entries. For example: /bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/X11R6/bin:/opt/mozilla

ie. (for Bourne based shells)
PATH="$PATH:/usr/local/bin"
export PATH

DISPLAY - Tells the machine where to display graphical applications

ie. (for Bourne based shells)
DISPLAY="name_of_machine:0.0"
export DISPLAY
export - In Bourne based shells (ksh appears to be default on Solaris), this command is used to set an environment variable.
setenv - csh based shells use the setenv command to set environment variables. ie.
setenv PATH "$PATH:/usr/local/bin"

[Squashman]

Originally posted by healtheworld:
To get those darn windows/dos text files to parse properly, get rid of the carriage return at the end of every line....

code:--------------------------------------------------------------------------------sed -e 's/.$//g' foo.txt -i--------------------------------------------------------------------------------

Isn't that what they created Unix2dos and Dos2Unix for.

I'm not harping on you, it is nice that you posted this stuff but I kind of feel that most of it is unneccassary.

Hope you are having fun with your topic.

Its not that...
The only reason for starting this thread is to get some of the knowledge from experts..

How do I access my computer running Linux from my Windows desktop?
***********************************************
There are multiple ways to do this.

If you are content with just accessing the Linux console, you can use ssh or telnet.
Alternately, you can use HyperTerminal? or something similar to access your Linux console over a serial port. Doing this is beyond the scope of this answer; however, this document covers this information. (Most of the HOWTO covers how to use an actual hardware terminal, which is what the likes of HyperTerminal? emulate. The section I have linked to covers setting up your Linux computer.)

If you want to access files on your Linux computer, you can set up Samba to have it show up as a network resource under network neighborhood. For now, see http://samba.linuxbe.org/ for a nice, friendly tutorial on setting up Samba.

If you wish to have access to the Linux GUI, there are two major ways to do this.




You could obtain and run a piece of software known as an "X11 server" on Windows. Popular commercial X11 servers include Hummingbird eXceed, StarNet X-Win32 and MicroImages MI/X.

Free-of-cost open-sourced X11 servers for Windows include WeirdX (written in Java) and Cygnus XFree86 (somewhat hard to set up).

Install the X11 server on your Windows desktop.

Now, it depends if you have Linux boot into a GUI (i.e., whether or not your have a graphical login screen instead of a console login).

If you have a graphical login, you can use the XDMCP feature of the X11 server on your Windows desktop to connect to your Linux server's xdm service (which provides graphical login). Connect to yourlinuxmachine:0.

If you log in on console, set up SSH on your Linux machine and install an SSH client on your Windows machine. Set up the SSH client to enable X11 forwarding (this should be one of the available configuration options).

Most modern distributions have SSH already set up for X11 forwarding. However, the official OpenSSH? distribution does not. In order to enable X11 forwarding on the server, log in as root. Locate the file sshd_config using the command

locate sshd_config

(typically /etc/sshd_config or /etc/ssh/sshd_config)

and use a text editor (like vi, nedit, gedit or kedit) to edit it. See if there's a line such as

#X11Forwarding yes

(note the # sign). If so, remove the # before X11Forwarding. (If there's no # sign, you don't have to do anything. If there's a `no' instead of a `yes', change it to a `yes'.)

Save the file and exit your editor. Restart your computer or the ssh daemon to have the changes go into effect.

Now you can run the X11 server on your Windows desktop and use SSH to connect to your Linux machine. Start any GUI program in your SSH console, and its windows should pop up on your Windows desktop.


The other option is to use VNC. VNC is a fantastic little remote access system, available for most UNIX operating systems, as well as for Windows and the Mac OS.

Obtain the VNC server binary package for Linux and install it. Run vncpasswd and set a remote access password (and remember it!). Start the VNC server:

vncserver :10 -geometry 800x600 -depth 24

Obtain and install the VNC viewer for Windows on your Windows desktop. Run it, and connect to yourlinuxmachine:10.

The neat thing about VNC is that it also comes with a Java applet client and acts as a web server. You can start up a Java-capable web browser and access

http://yourlinuxmachine:5810

and the Java applet should load and start up. Note, however, that the performance of the Java applet client is nowhere near as good as that of the native Windows client.


If you just want the advantages of having UNIX command-line utilities on your Windows desktop, you don't need to run Linux at all for this. .

Due to the nature of Linux distribution, the method is distribution-specific.

The first thing to be done is to set up your network interface. (This is usually Ethernet if your machine is on a LAN, on a cable modem or DSL modem.)

If your connection is ADSL using PPP-over-Ethernet (PPPoE?), you do not need to set up DHCP. Instead, obtain the PPPoE client and install and configure it, and you should be done.

Setting up PPP-over-ATM (PPPoA?) for ADSL connections is not easy. The hardware support is sparse, and the ATM support itself is raw. If you're feeling adventurous, try this. Again, you do not need to install DHCP in this case, if you get it working.

You also do not need to set up DHCP if you are on a dial-up (PPP) connection.

If you are using a PC Card or CardBus? network interface, please see the notes at the end of this answer as well.

If you are running Red Hat Linux, Mandrake Linux, TurboLinux?, Yellow Dog Linux, Gentus Linux, or another Red-Hat-like distribution:

Set up a DHCP client daemon, notably pump. Check if you already have it installed with

rpm -q pump

If it isn't already installed, insert your CD-ROM into the CD-ROM drive and mount it.

mount /mnt/cdrom

Find the pump rpm on the CD-ROM.

find /mnt/cdrom -name \*pump\ -print

Install the corresponding RPM.

rpm -i /mnt/cdrom/RedHat/RPMS/pump-x.x.x[i]-[i]x.i386.rpm

Do one of the following to set up a network device:




Run netcfg. This requires you to have set up a X11-based GUI. Click on the Interfaces button. Click Add. Choose the type of interface you are using. Choose DHCP from the interface configuration protocol[. Click Done. Now select the new interface (typically eth0) and click Activate. Test your connection by pinging a server you know of. If it works, click Save and then Quit. You are now done.

Edit /etc/sysconfig/network-scripts/ifcfg-eth0. (Replace eth0 with the interface name. eth0 is the first Ethernet device.)

code:
--------------------------------------------------------------------------------

DEVICE=eth0BOOTPROTO=dhcpONBOOT=yes
--------------------------------------------------------------------------------


Save and restart.


This will set up the Ethernet interface. If your interface has already been set up, following the instructions above (editing instead of adding, etc.) will set up your system to use DHCP.

If you are running SuSE Linux:

Make sure you have the DHCP client installed. Insert and mount your CD-ROM and look for and install the dhclient package if it isn't already installed.

Set up your network interface with YaST? if you haven't already. Run yast as root. Select System administration > Integrate hardware into system > Configure networking device. At the Network type prompt, select eth0. Select the type of card at Networking device type. Choose Continue.

Next, set up the DHCP client by selecting System administration > Network configuration > DHCP clientand configuring it.

Save the configuration and restart.

Note that SuSE's dhclient (yet another DHCP client) package hard-codes eth0 as the interface to listen for. You may need to edit /etc/dhclient.conf.

If you are running Debian GNU/Linux:

Set up your network interface. This may involve adding a line such as

alias eth0 networkmodule

to /etc/conf.modules (where networkmodule is the kernel driver module for your network card).

Mount your CD-ROM drive and type

apt-get -f install dhcpcd

This should install the DHCP client daemon off the deb package provided on your CD-ROM.

If you are running Slackware Linux, use netconfig to set up the network interface and DHCP.

Here are generic instructions to set up DHCP.

Build a kernel with support for your ethernet adapter (or compile it as a module). For now, refer to this NHF if you do not know what this means.

Download the dhcpcd source tarball from ftp://ftp.phystech.com/pub/ .

Unpack it:

tar xvzf dhcpcd-version.tar.gz

Build it:

cd dhcpcd-version
make
make install

Have dhcpcd run on startup. Edit /etc/rc.local (or /etc/rc.d/rc.local).Add the line

/usr/sbin/dhcpcd

to the file. Save and restart.

There are additional considerations in setting up a PC Card or CardBus? network adapter to use DHCP.

If you are using PCMCIA card services (likely if you're using a 2.2.x kernel, possible if you're using a newer one), edit /etc/pcmcia/network.opts and set the DHCP variable to y. Also configure the network interface not to start on bootup, since you want the card service to detect and initialize the network interface rather than the initialization scripts.