THIS IS MOSTLY JUST A COMPILATION OF STUFF I GOT OFF THE INTERNET. I WROTE SOME OF THE THINGS BELOW BUT NOT MOST OF THEM.
Kernel compile ......
tar xjvf linux-.
cp -R linux-. /usr/src
cd /usr/src
rm linux
ln -s linux-. linux
make mrproper
make gconfig (xconfig)
make bzImage
make modules
make modules_install
# pwd
/usr/src/linux-2.6.0-test4
# mv arch/i386/boot/bzImage /boot/bzImage-2.6.0-test4
# mv System.map /boot/System.map-2.6.0-test4
# cd /boot
# rm System.map
# ln -s System.map-2.6.0-test4 System.map
add link to grub.conf
Disable/enable supermount ......
/usr/sbin/supermount -i enable
Common commands ......
rpm -ihv sfaljfsald.rmp
tar -xzvf lasfdjlafdsj.tar.gz
tar -xvf alsdfj.tar
tar -xjvf alklfdsaj.tar.b2z
unrar e(x) asdldlsfakjfsd.rar
bchunk BIN CUE NAME
vcdxrip -b BIN -o OUTPUT
How to mount ISO image under Linux?..........
1) Must be login as root user if not user switch to root user using:
# su -l
2) Create the directory aka mount point:
# mkdir -p /mnt/disk
3) Use mount command as follows (assumes that your ISO file name is disk1.iso):
# mount -o loop disk1.iso /mnt/disk
4) Change directory to list it:
# cd /mnt/disk; ls -l
mount -t iso9660 /home/sancho/downloads/reactos.iso /mnt/disk/ -o loop
CD burning........
Data CD : k3b no problems
Audio CD: k3b from MP3 or OGG... NO CDTEXT
BINs and CUEs > # cdrdao write --device /dev/hdc image.cue
VCD from MPEG > vcdxbuild > # cdrdao write --device /dev/hdc image.cue
ISO's > cdrecord dev=/dev/hdc isoimage.iso (or k3b)
Get your cd-recorders device name (not working with ide and kernel 2.6)
# cdrecord -scanbus
Get your cd-recorder device name (with an IDE device and kernel 2.6)
# cdrecord -scanbus dev=ATAPI
Burning an iso-image
To burn an iso-image run (replace /dev/hdc with the name of your recording device):
# cdrecord dev=/dev/hdc isoimage.iso
Burning a bin/cue
To burn a bin/cue image run (replace /dev/hdc with the name of your recording device):
# cdrdao write --device /dev/hdc image.cue
Making an iso-image from an existing cd
To copy an existing cd just type (replace /dev/hdc with the name of your recording device):
# dd if=/dev/hdc of=/home/user/isoimage.iso
Or use readcd program, also in the cdrtools package
# readcd -v dev=/dev/hdc -f isoimage.iso
If the original cd was bootable it will be a bootable image.
Making an iso-image frome existing files on harddisk
To make an iso-image just copy the needed files to one folder, then do a
# mkisofs -J -R -o isoimage.iso ~/folder
OK the idea is to have the kernel properly configured and then tell 'lilo' to not see the drive as a normal IDE/ATAPI device but hold it and use the ide-scsi module.First check the cdrom writing how-to for this section:
Sect. Description Module SCSI IDE PP
------------------------------------------------------------
BLOCK Enhanced IDE/MFM/RLL...... Y
BLOCK IDE/ATAPI CDROM ide-cd... M
BLOCK SCSI emulation support ide-scsi... M
BLOCK Loopback device loop... M
SCSI SCSI support scsi_mod Y/M
SCSI SCSI CD-ROM support sr_mod Y/M
SCSI Enable vendor-specific Y
SCSI SCSI generic support sg Y/M
SCSI (select a low-level driver) Y
FS ISO 9660 CDROM filesystem iso9660 Y/M
FS Microsoft Joliet cdrom... joliet Y
and make sure your kernel is set as above. Set the ones above that show only a 'Y' compiled into the kernel and set the ones with 'Y/M' as modules. After you make the kernel you can edit lilo.conf and add an append line as follows:
append = "hdd=ide-scsi"
where 'hdd' is your particular device for your setup.
Now on to /etc/modules.conf add the line:
alias scsi_hostadapter ide-scsi
and reboot: You should be able to 'cdrecord -scanbus' and see the drive there.
You will need 'cdrecord' and any programs you want depending on if you want to rip cd's or whatever.
I use 'gcombust' which requires programs like cdrecord/mkhybrid/cdlabelgen/mkisofs etc...
Since the kernel is built with 'generic scsi support' you can mount the drive as before with something like this:
mount -t iso9660 /dev/sr0 /mnt/cdrom
where 'sr0' may change depending on your hdware. I have a tape drive on sr1 and the cdrw on sr0. 'cdrecord -scanbus' will guide you here.
Laptop wireless....
http://www.linuxquestions.org/hcl/showproduct.php?product=810
Description: This is used with kernel 2.6.3 - 2.6.4
I went to ndiswrapper's site and downloaded the cvs ndiswrapper - basically it is version 5 + cvs.
but anyway, open a Konsole and type
$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndiswrapper login
When prompted for a password for anonymous, simply press the Enter key
$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndiswrapper co ndiswrapper
This is the cvs website instruction ndiswrapper cvs
It will download the cvs ndiswrapper to a file callled ndiswrapper
If you have installed a previous ndiswrapper, uninstall it by running "make clean" in that directory
and you can leave the alias entry in "/etc/modprobe.conf" and the ndiswrapper directory "/etc/ndiswrapper/bcmwl5"
I created an file in "/etc/sysconfig/network-scripts/" called ifcfg-wlan0 and this is what it contains
DEVICE=wlan0
BOOTPROTO=dhcp
onBOOT=no
MODE=Managed
ESSID=any
Basically I want dhcp to automatically detect and configure wlan0.
Go to the ndiswrapper directory as root and somewhat follow the instructions
# make install
# ndiswrapper -i /etc/ndiswrapper/bcmwl5/bcmwl5.inf
--- this is the directory for the inf from the previous install of ndiswrapper-0.5
# ndiswrapper -l
-- make sure it says "bcmwl5 present" because I had to try almost three different drivers and I settled on the emachine driver.
# modprobe ndiswrapper
# dmesg --you will see a log about the driver been loaded if you do
then
# ndiswrapper -m
# iwconfig -- to make sure you device is recognized
and finally
# ifup wlan0
Some modification my be necessary so read the "INSTALL" documentation that came with ndiswrapper.
Finally I must say Kudos to the developers at ndiswrapper
Keywords: Broadcom Wireless card in Compaq Presario 2195us
/sbin/lspci output: Network controller: Broadcom Corporation BCM94306 802.11g (rev 02)
Chipset:
Connection Type: Mini-PCI
I used this on the linksys version of this chipset, which is a PCI54g
First off, make sure that lspci will pick up your card.
Should be something with 14E4:xxxx
I found that older mother boards will not "see" this card and lspci won't show it. Though if it does, it works great with ndiswrapper and the second recommended driver from the ndiswrapper recommended driver page.
I used ndiswrapper 0.7 compiled from the sources from here
http://ndiswrapper.sourceforge.net/
and as mentioned used the second recommended driver for this chipset from this page
http://ndiswrapper.sourceforge.net/supported_chipsets.html
Then downloaded the wireless tools sources from
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
The link to the sources is
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/wireless_tools.26.tar.gz
Went through the process of "installing" the windows drivers with ndiswrapper as described further up.
Then I ran iwconfig and saw details on my wireless (wlan0)
Then did
iwlist wlan0 scan
and it showed my AP (Access Point) with it's frequency and ESSID
I got the channellist with
iwlist wlan0 channel
noted the corresponding channel, then with the same ESSID (which was "test") I did
iwconfig wlan0 channel 11 essid "test" mode Managed
next time I ran iwconfig it showed the changed frequency and the MAC of the AP. As I was running a dhcp server on the AP all that was left was to run was
dhcpcd wlan0
cheers
newbee
Disable ACPI.....
at install prompt linux acpi=off nolapic napic
Running a graphical app over SSH....
1.
The client has to run an X server.
2.
To allow the client to receive X data from the host (the application server), type xhost +name_or_IP_of_host
If you can connect to the remote via SSH, you can run X applications very easily - and more secure - via an SSH tunnel.
3.
Login into the host machine and export the display by running
export DISPLAY=name_or_IP_of_client:0
4.
Start a program of your choice on the host from the client machine.
Method #3:
xhost +RemoteIP
ssh/telnet RemoteIP
export DISPLAY="LocalIP:0.0"
RemoteApp &
Remote X sessions ...
http://www.linux-mag.com/2003-03/guru_01.html
Simplifying Remote VNC Logins
by Roderick W. Smith
Virtual Network Computing (VNC) is an increasingly popular remote-access protocol. VNC is available for Linux, Windows, Mac OS, and others. (If you're unfamiliar with VNC or don't have VNC installed on your Linux system, see this month's "Tech Support" column on page 62 for instructions on how to install and use VNC.)
Unfortunately, VNC's usual method of operation is clumsy in some ways. VNC users may need to log in via ssh and run the VNC server manually. Although VNC asks for a password, it doesn't ask for a username, so users need to log on using a specific VNC session number -- an awkward restriction.
Fortunately, there's a solution: you can launch a VNC server in such a way that it uses an X Display Manager Control Protocol (XDMCP) server running on the same computer. Linux systems normally run XDMCP servers to handle local GUI logins -- so when somebody uses VNC to connect to a computer that's configured with VNC and XDMCP, VNC displays a normal Linux GUI login prompt. This enables users to enter a username and password, and perhaps even dispense with the VNC session number.
Before proceeding, you should obtain and install a VNC server. The widely-used AT&T VNC package comes with most Linux distributions or you can download it from http:// www.uk.research.att.com/vnc (or you can use a variant such as TightVNC, found at http://www.tightvnc.com). You'll also need an XDMCP server, such as the X Display Manager (XDM), KDE Display Manager (KDM), or GNOME Display Manager (GDM). At least one of those display managers is normally installed with X.
Let's look at VNC and XDMCP separately and then see how they can be combined into something more powerful.
VNC's Method of Operation
On a Linux computer, a VNC server is really two servers in one. The first server typically accepts remote connections using the VNC protocol. This server sends display data to the VNC client and also receives keystrokes and mouse activity from the client.
guru_01
Figure One: VNC Components and Relationships
The second part of a VNC server is an X server. A traditional X server provides an interface to a video card, keyboard, and mouse, but the VNC X server instead links to the remote computer. This arrangement is illustrated in Figure One.
Users normally run the VNC server using the vncserver script. This script calls the Xvnc program, which is the actual X and VNC server. A user accesses VNC by logging in remotely, running vncserver, and then running a VNC client to access the newly-started VNC server. As part of the startup process, the VNC server returns a session number. In a multi-user environment, each user receives a different VNC session number.
This configuration has a couple of big drawbacks: the user has to login twice -- once via ssh (say) to run vncserver and again to login via XDMCP -- and the user has to remember the VNC session number.
This typical configuration also has an unusual feature that may be an advantage or a disadvantage, depending upon your needs: VNC sessions are persistent -- they remain intact even when a user disconnects from the VNC server. So, a user can start a VNC session, close it without exiting from running programs, and begin again with running programs open and in the state in which they were left. This feature can be convenient, but it can also cause problems (such as excessive memory use) if users forget about their "abandoned" VNC sessions. Moreover, on a system with many users, having many VNC servers running at all times can be a drain on available memory.
Traditional Linux X-Based Logins
Most Linux distributions today install X and configure it to launch automatically when the computer starts. In this configuration, an XDMCP server is used to mediate logins. Typically, a startup script launches the XDMCP server, which in turn starts X. The XDMCP server takes control of the local X display and presents a GUI login screen.
An XDMCP server can do much more than display a local login screen, though. An XDMCP server can accept connections from remote X servers, performing the negotiations necessary to allow local X programs to use the remote X server. Ultimately, we'll use this feature to have XDMCP improve VNC.
Most Linux distributions ship with security-conscious XDMCP configurations that disable many of the XDMCP server's capabilities -- after all, you don't want to expose your computer to would-be intruders for no reason. Thus, part of what you must do to enable VNC to work with XDMCP is to reconfigure XDMCP to accept some types of login requests. Unfortunately, this is easier said than done because there are three major XDMCP servers in common use: XDM, KDM, and GDM. Each of these tools has its own configuration files and quirks.
Configuring an XDMCP Server For VNC
To use XDMCP with VNC, your XDMCP server must accept connection attempts from the local computer. Ordinarily, the XDMCP server doesn't accept such connections. It just manages the local X display. Precisely how you do this depends upon the XDMCP server your system runs. If you're not sure which XDMCP server your system uses, type ps ax | grep dm and examine the output for one of the XDMCP server names. Of course, the XDMCP server must be running for this to work, and that's only likely to be true if your system is configured for GUI logins. On most distributions, setting the system to use runlevel 5 will do this. Type telinit 5 to enter runlevel 5 until you reboot or change it manually. You can also edit /etc/inittab and change the number in the id line to 5 to change the runlevel permanently.
The simplest XDMCP server to reconfigure is GDM, which is the default for Red Hat and some other distributions. Open /etc/X11/gdm/gdm.conf in your favorite editor and locate the [xdmcp] section. Change the line that reads enable=false to enable=true. This line reconfigures GDM to function as a network-enabled XDMCP server and to accept remote login requests. If you prefer, you can use the gdmsetup program to edit gdm.conf. Click the "XDMCP" tab and check the "Enable XDMCP" box.
XDM's configuration files usually reside in /etc/X11/xdm, and some versions of KDM use those files as well. More recent versions of KDM use similar files in another directory, typically /etc/kde2/kdm, /opt/kde/share/config/kdm, or something similar.
For both KDM and XDM, one critical file is Xaccess. The Xaccess file controls who can access the XDMCP server. For the configuration described here, a line that reads localhost should do the job. To open the XDMCP server to any remote system, * works. (Note that the XDMCP server program doesn't need to accept remote connections for remote, VNC-mediated logins to work -- it's only the VNC server program that needs to accept such access.)
XDM's main server options are set in a file called xdm-config. To have the server listen for connection requests from a VNC X server or other computers, you must tell it to listen to port 177 with a line like this:
DisplayManager.requestPort: 177
The default configuration on most systems substitutes 0 for 177, which keeps the server from listening for connection requests. In recent versions of KDM, the same task is accomplished through a line that reads Enable=true in the kdmrc file.
Whatever XDMCP server you use, it's a good idea to implement firewall rules to keep unwanted individuals out. This is particularly true of GDM, which doesn't include any access control tools akin to XDM or KDM's Xaccess file.
For instance, to let only localhost access the XDMCP port, you could use rules like this:
# iptables -A INPUT -s 127.0.0.1 -p udp \ --dport 177 -j ACCEPT
# iptables -A INPUT -p udp --dport 177 -j DROP
To make these changes permanent, enter these rules in an appropriate startup or firewall script.
After you've created the firewall rules and reconfigured the XDMCP server, you must restart the server, or at least pass it a USR1 signal to tell it to reread its configuration file. In either case, you must log out of any active X sessions, so the simplest way to do it is to log out and then restart the XDMCP server. You can do this by typing killall xdm (or whatever the server executable name is). Chances are that X will shut down, and you may need to restart your XDMCP server manually.
At this point, the XDMCP server should be up and running, but you won't be able to make a VNC connection yet. If, after completing the VNC configuration (described in the next section), you can't get it to work, you can try another XDMCP server -- sometimes one will work when another obstinately refuses to function with VNC.
For instance, KDM doesn't work with VNC under SuSE, although GDM works under SuSE, and KDM works with other distributions. To change the XDMCP server, install a second one and then dig around in your configuration files to change the default. In Red Hat or Mandrake, edit /etc/sysconfig/desktop and add a line that sets the DISPLAYMANAGER variable to GNOME for GDM, to KDE for KDM, or to XDM for XDM. In SuSE, change the DISPLAYMANAGER variable in /etc/sysconfig/displaymanager to gdm, kdm, or xdm. In Debian, place the complete path to the XDMCP server's binary in /etc/X11/default-display-manager.
Launching VNC From a Super Server
Once XDMCP is configured to run, you need to set up VNC. The simplest way to do this is to launch VNC from a super server such as inetd or xinetd). To do that, you must first specify one or more VNC ports in /etc/services:
vnc-800x600 5900/tcp
vnc-1024x768 5901/tcp
If you want to enable multiple VNC logins using multiple virtual resolutions, specify more than one VNC port, as shown immediately above. Port 5900 (the default VNC port) accepts 800x600 logins, while 5901 accepts 1024x786 logins.
If you only want to support one virtual resolution, you need only one entry. The entry for port 5900 should correspond to whatever you want the default resolution to be. Note that you're not restricted to traditional resolutions, and in fact, using resolutions slightly lower than is normal, such as 950x700 instead of 1024x768, can be useful. Such resolutions leave room for window borders around the VNC client window.
If your system uses xinetd, as Red Hat and Mandrake do, you need to create a file in /etc/xinetd.d corresponding to the new VNC server. You can call this file vnc, and it should include entries like this:
service vnc-800x600
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/X11R6/bin/Xvnc
server_args = :1 -inetd -query localhost \
-geometry 800x600 -depth 24 -once \
-fp unix/:7100
}
The server_args line is very important, and must be customized for your system. In particular, you should set the -geometry value to whatever resolution you want to use, and -depth to the bit depth. The -fp option is very important: this sets the VNC X server's font path. This example sets the font path to unix/:7100, which is appropriate for a Red Hat system. Consult the FontPath entries in your /etc/X11/XF86Config file and enter all the directories referenced there on this line, separated by commas, such as -fp /usr/fonts,/opt/fonts.
If your system uses inetd, the procedure is similar, but inetd uses a single-line for each of its entries. The inetd equivalent to the preceding xinetd example is:
vnc-800x600 stream tcp nowait nobody \
/usr/sbin/tcpd /usr/X11R6/bin/Xvnc :1 \
-inetd -query localhost -geometry 800x600 \
-depth 24 -once -fp unix/:7100
The line shown above has been split across several lines due to column width constraints -- it should be entered on just one line in /etc/inetd.conf, even if it's longer than 80 columns.
Of course, if you want to support multiple resolutions, you need to create multiple inetd or xinetd entries, one for each resolution. Each entry needs a unique port number reference -- one for vnc-800x600, one for vnc-1024x768 (or whatever names you specified in /etc/services). You should also change the :1 server argument for subsequent entries. This argument sets the local X server display number, which must be unique for each call. You can also implement firewall rules to accomplish the same goal.
If you want to implement restrictions on who may access the VNC server, you can do so using the usual access control tools for your super server -- TCP Wrappers for inetd or xinetd's built-in access control tools. Implementing such restrictions is a very good idea. Without them, anybody who can reach your computer and who has a username and password can log in.
After you've created the super server configuration, you need to restart the super server, or at least pass it a SIGHUP to have it reload its configuration file. Typing killall -HUP inetd or killall -HUP xinetd should do the trick.
Testing the Result
guru_02
Figure Two: A Typical VNC/XDMCP login display
At this point, you should have a VNC server running that handles logins for all users. On the VNC server system, type vncviewer localhost. A VNC screen should appear, and after a few seconds, an XDMCP login should appear within it, much as shown in Figure Two.
You should be able to type your name and password and be greeted by your usual X desktop. If this works, try the same operation from another computer. If you have problems with either local or remote access, re-examine your configuration. Check /var/log/messages for error messages from the super server when you restarted it; perhaps there's a typo in your service specification or some similar problem.
If you see a VNC screen but no XDMCP prompt, examine your XDMCP configuration or try another XDMCP server. One common source of problems is with the font path. Try removing the -fp specification, including all its directories. If that works, try adding the-fp specification back and add directories one or two at a time to localize the problem.
Once the VNC/XDMCP combination is working, many users can log in simultaneously, using the same VNC session number. Instead of being tied to users, the VNC session numbers specify different VNC resolutions or other options, as defined by the Xvnc call in the super server configuration.
When logging into a VNC/XDMCP server, the user's normal GUI environment is run. GDM and KDM both typically allow a user to select the desktop environment to be used. This may be easier for users to manage than the typical VNC X configuration file. One note: a VNC/XDMCP configuration loses the session persistence of a more traditional VNC configuration -- when a user logs out, the session is closed and all the programs the user launched are shut down.
On the whole, a VNC/XDMCP combination is very user-friendly and makes it easy to configure Windows clients to access a Linux system. Initial configuration may take a little longer, but the effort is well worth it.
Install gdm
boot and init settings > turn off always dissallow remote conncetions
Xnest :1 -query SERVER IP -geometry 800x600
VNC server
vncserver :1 -geometery 800x600 (start manually or add to startup script)
client serverip:1
X11VNC
http://www.karlrunge.com/x11vnc
download and install. exports current display to vnc server.
x11vnc
x11vnc stop
How can I use x11vnc to connect to an X login screen like xdm, GNOME gdm, KDE kdm, or CDE dtlogin? (i.e. nobody is logged into an X session yet).
Continuously. Have x11vnc reattach each time the X server is restarted (i.e. after each logout):
To make x11vnc always attached to the the X server (please consider the security implications of this!) including the login screen you will need to add a command to the display manager startup script. The name of the script file depends on desktop used and seem to be:
GNOME /etc/X11/gdm/PreSession/Default
KDE /etc/kde*/kdm/Xsetup
XDM /etc/X11/xdm/Xsetup
CDE /etc/dt/config/Xsetup
although the exact location can depend on operating system and distribution. See the documentation for your display manager: gdm(1), kdm(1), xdm(1), dtlogin(1) for additional details. The above Dtlogin*grabServer:False step will be needed for dtlogin here as well. There may also be display number specific scripts: e.g. Xsetup_0 vs. Xsetup.
In any event, the line you will add to the script will look something like:
/usr/local/bin/x11vnc -rfbauth /path/to/my/vnc/passwd -forever -bg
where you should customize the exact command to your needs. You may want to redirect the x11vnc output to a separate log file for debugging. In that case replace the -bg above with something like:
1>> /var/tmp/x11vnc.log 2>&1 &
(or use the "-o logfile" option).
If you do not want to deal with the display manager startup scripts, here is a kludgey script that can be run manually or out of a boot file like rc.local. x11vnc_loop It will need some local customization before running. Because the XAUTHORITY auth file must be guessed by this script, use of the display manager script above is preferred.
/usr/local/bin/x11vnc -forever -bg -scale 2/3 -shared
Laptop touchpad
Do you have a laptop with a touchpad that will not tap? Is that touchpad a Synaptics touchpad?
I went through that myself, and I decided to write a howto to ease your pain ;)
Find this HOWTO at http://fred.blaisern.com/HOWTOS (OpenOffice Writer format)
Introduction:
This how-to is written after my own experience on a Dell Inspiron 5150 (3.06ghz w/ HT enabled) with Slackware 9.1, Xfree 4.3.0 and kernel 2.6.1 stable. I had to spend quite a few hours on it, so I figured this may be helpful to someone. As of today, the synaptics Xfree driver version is 0.12.3.
Figure out whether or not you have a synaptics touchpad:
To figure out whether or not you have a Synaptics touchpad on your laptop, execute the following command once you log on:
dmesg |more
and look for something like this (on my machine):
Synaptics Touchpad, model: 1
Firmware: 5.9
Sensor: 37
new absolute packet format
Touchpad has extended capability bits
multifinger detection
palm detection
input: SynPS/2 Synaptics TouchPad on isa0060/serio1
If you see this (or something close), then you most probably have one.
Kernel configuration:
Under Device Drivers > Input Device Support, make sure you have the Event Interface selected, either as a module or compiled into the kernel. (module name 'evdev'). If you compiled it as a module, you will need to load it up before X comes up. On slackware, you can do this by editing your rc.local file, and add 'modprobe evdev'.
Note: From my own experience, it didn't work when i compiled it into the kernel. I have no idea why... maybe a bad compile, who knows...
Also, make sure you have PS/2 mouse compiled in. ( Device Drivers > Input Device Support > Mice )
Driver configuration:
To take advantage of the Synaptics touchpad, you will have to have the XFree driver that you can download from here:
http://w1.894.telia.com/~u89404340/touchpad/index.html
Uncompress the sucker and untar it. (Note: in case you are reading the INSTALL file, the CONFIG_MOUSE_PS2_SYNAPTICS configuration option doesn't exist anymore, so don't look for it.)
Go into the newly created directory, and type 'make'. This will build the driver. (synaptics_drv.o). There is another driver (synaptics.o), but do not worry about this one.
su to root, and perform a 'make install'. This will copy the driver to its right location (usually /usr/X11R6/lib/modules/input/... copy it manually if your path is different). At this point, you are now ready to modify your XF86config.
XF86Config configuration:
Several things here:
- Create a backup of your existing XF86Config.
- You need to load the synaptics module (in the module section, top of the file):
Load "synaptics"
- Add/Replace in the InputDevice section for the touchpad the following lines (from INSTALL file):
Section "InputDevice"
Driver "synaptics"
Identifier "Mouse1"
Option "Device" "/dev/psaux"
Option "Protocol" "auto-dev"
Option "LeftEdge" "1900"
Option "RightEdge" "5400"
Option "TopEdge" "1900"
Option "BottomEdge" "4000"
Option "FingerLow" "25"
Option "FingerHigh" "30"
Option "MaxTapTime" "180"
Option "MaxTapMove" "220"
Option "VertScrollDelta" "100"
Option "MinSpeed" "0.02"
Option "MaxSpeed" "0.18"
Option "AccelFactor" "0.0010"
Option "SHMConfig" "on"
# Option "Repeater" "/dev/ps2mouse"
EndSection
Note: If you are a strict 2.6 kernel user, you can also set Device to (most likely) /dev/input/event0, and Protocol to event. You can figure out the the X in eventX by looking at your /proc/bus/input/devices file.
- If you were within an X session, type 'init 3' as root to drop back to a command line prompt, then try to start X again with the new XF86Config. Observe any error messages that could show up.
- Test it!!!
Adding a second mouse:
Once you have that synaptics stuff working, you will not be able to use an external mouse just by plugging it in. Well maybe, not on Slackware anyway :P Either way, if just plugging in a 2nd mouse doesn't do it, read on.
If you want to add a second mouse (in my case a USB mouse), you will have to append your XF86Config file in this manner:
Create another InputDevice section for your (2nd) mouse, much like this:
Section InputDevice
Identifier Mouse2
Driver mouse
Option Device /dev/psaux
Option Protocol IMPS/2
Option ZaxisMapping 4 5
EndSection
You then have to look for the ServerLayout section (most likely at the bottom). You will see something like:
InputDevice Mouse1 CorePointer
Since you can only have 1 core pointer, add this right underneath:
InputDevice Mouse2 AlwaysCore
Note: Refer to Xfree.org for more detailed info at:
http://xfree.org/4.3.0/mouse5.html#21
---VIRTUAL SERVER----
DIFFERENT HOME DIRS
useradd -D chage defaults
or /etc/defaults/useradd
/etc/skel for skeleton build directory
useradd %user%
passwd %user% to create account
DNS
Install bind
Install named cache
FTP CONF
# This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use. It establishes a single server
# and a single anonymous login. It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.
ServerName "ProFTPD Default Installation"
ServerType standalone
DefaultServer on
# Allow FTP resuming.
# Remember to set to off if you have an incoming ftp for upload.
AllowStoreRestart on
# Port 21 is the standard FTP port.
Port 21
# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022
# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances 30
# Set the user and group under which the server will run.
User nobody
Group nogroup
# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
DefaultRoot /var/www sancho
DefaultRoot ~
# Normally, we want files to be overwriteable.
AllowOverwrite on
HideFiles "(\\.htaccess|.bash_logout|.bash_profile|.bashrc|.mailcap|.screenrc)$"
# Needed for NIS.
PersistentPasswd off
# Default root can be used to put users in a chroot environment.
# As an example if you have a user foo and you want to put foo in /home/foo
# chroot environment you would do this:
#
# DefaultRoot /home/foo foo
#DefaultRoot /var/www sancho
AllowRetrieveRestart on
AllowStoreRestart on
MaxClients 20 "To many users right now come back later."
MaxClientsPerHost 3 "Your IP address has to many sessions open. Close threads or wait for the ghosts to time out. "
PassivePorts 2100 2150
ServerIdent on "Welcome to the FDAM FTP server. "
ShowSymlinks on
AccessDenyMsg "Bad login and or password."
AccessGrantMsg "Account authorized, continuing..."
AllowOverwrite on
QUOTAS
compile kernel with quota support
install quota tools
http://www.siliconvalleyccie.com/linux-adv/quota.htm
Setting Up Quotas
In our example, the family Linux server is running out of space in the /home filesystem due to a lot of MP3 downloads.
Enter Single User Mode
As we'll need to remount the /home filesystem it's best to ensure that no other users or processes are using it. This is best achieved by entering single user mode from the console. This may be unnecessary if you are certain that you're the only user on the system.
[root@bigboy tmp]# init 1
Edit Your /etc/fstab File
The /etc/fstab file lists all the partitions that need to be auto-mounted when the system boots. You have to alert Linux that quotas are enabled on the filesystem by editing the /etc/fstab file and modifying the options for the /home directory. You'll need to add the usrquota option. In case you forget the name, the usrquota option is mentioned in the fstab man pages.
Old fstab
LABEL=/home /home ext3 defaults 1 2
New fstab
LABEL=/home /home ext3 defaults,usrquota 1 2
Remount The Filesystem
Editing the /etc/fstab file isn't enough, Linux needs to reread the file to get its instructions for /home. This can be done using the mount command with the "-o remount" qualifier.
[root@bigboy tmp]# mount -o remount /home
[root@bigboy tmp]#
Create The Partition Quota Configuration Files
The topmost directory of the filesystem needs to have a aquota.user file (Defines quotas by user) and/or a aquota.group file (Defines quotas by user). The man page for "quota" lists them at the bottom.
In this case we'll just enable "per user " quotas.
[root@bigboy tmp]# touch /home/aquota.user
[root@bigboy tmp]# chmod 600 /home/aquota.user
[root@bigboy tmp]#
Make Linux Read The Quota Config File
This is done using the quotacheck command. You'll get an error the first time you enter the command as Linux will realize that the file wasn't created using one of the quota commands.
[root@bigboy tmp]# quotacheck -vagum
quotacheck: WARNING - Quotafile /home/aquota.user was probably truncated. Can't save quota settings...
quotacheck: Scanning /dev/hda3 [/home] done
quotacheck: Checked 185 directories and 926 files
[root@bigboy tmp]#
Edit The User's Quota Information
Now we need to edit the user's quota information. This is done with the edquota command which allows you to selectively edit a portion of the aquota.user file on a per user basis.
[root@bigboy tmp]# edquota -u mp3user
The command will invoke the vi editor which will allow you to edit a number of fields.
Disk quotas for user mp3user (uid 503):
Filesystem blocks soft hard inodes soft hard
/dev/hda3 24 0 0 7 0 0
Blocks: The amount of space in 1K blocks the user is currently using.
Inodes: The number of files the user is currently using.
Soft Limit: The maximum blocks/inodes a quota user may have on a partition. The role of a soft limit changes if grace periods are used. When this occurs, the user is only warned that their soft limit has been exceeded. When the grace period expires, the user is barred from using additional disk space or files. When set to zero, limits are disabled.
Hard Limit: The maximum blocks/inodes a quota user may have on a partition when a grace period is set. Users may exceed a soft limit, but they can never exceed their hard limit.
In the example below we limit user mp3user to a maximum of 5 MB of data storage on /dev/hda3 (/home).
Disk quotas for user mp3user (uid 503):
Filesystem blocks soft hard inodes soft hard
/dev/hda3 24 5000 0 7 0 0
Get Out Of Single User Mode
Return to your original run state by using either the "init 3" or "init 5" commands.
Other Quota Topics
Enforcing Quotas
Once Linux is aware of users who have exceeded their quotas, the operating system subsequently prevents these users from creating more files or using more disk space in the partition.
Linux doesn't check quota usage each time a file is opened, you have to force it to process the aquota.user and aquota.group files periodically with the quotacheck command.
You can setup a cron job to run a script similar to the one below to achieve this.
#!/bin/bash
quotacheck -vagu
Editing Grace Periods
The "edquota -t" command sets the grace period for each filesystem. Like the edquota command, it invokes the vi editor.
The grace period is a time limit before the soft limit is enforced for a quota enabled file system. Time units of seconds, minutes, hours, days, weeks and months can be used. This is what you'll see with the command "edquota -t":
Note: There should be no spaces between the number and the unit of time measure. Therefore in this example, "7days" is correct and "7 days" is wrong.
[root@bigboy tmp]# edquota -t
Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
Filesystem Block grace period Inode grace period
/dev/hda3 7days 7days
Editing Group Quotas
Editing quotas on a per group basis can be done similarly with the "edquota -g" command.
Getting Quota Reports
The repquota command lists quota usage limits of all users on the system. Here is an example.
[root@bigboy tmp]# repquota /home
*** Report for user quotas on device /dev/hda3
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 52696 0 0 1015 0 0
...
...
...
mp3user -- 24 0 0 7 0 0
[root@bigboy tmp]#
EDIT PATH
edit .bash_profile or .bashrc in home dirs
STARTUP SCRIPT
/etc/rc.d/rc.local
WIRELESS STEPS
iwconfig wlan0 essid name default key 1000000001
ifconfig wlan0 192.168.0.145 netmask 255.255.255.0
route add default gw 192.168.0.1
------
ifconfig eth0 down
ifconfig wlan0 down
ifconfig wlan0 up
kwifimanager if needed
MOUNTING USB FLASH
su
modprobe usb-storage
mkdir /mnt/usbdrive
mount /dev/sda /mnt/usbdrive
INSTALLING NVIDIA DRIVER
sh NVI......
or
sh NV..... -k (kernel name)
kernel and module must both be built by same version of GCC
AUTO LOADING MODULE
add kernel module to /etc/modprobe.preload
-modprobe or insmod to insert
-lsmod to see
-rmmod to remove
-modinfo to get info
MOUNTING SMB
mount -t smbfs -o username=Administrator,password= //winsrv/Storage\ \(D\) /mnt/smb/winsrv/
FORCE UNMOUNT
fuser /mnt/cdrom - force unmount
UP DIR
s
MOUNTING NFS
mount 192.168.1.123:/backup -o user,tcp,rw,rsize=16384,wsize=16384 /mnt/nfs/backups
VNC SERVER ON FRESH MDK OR FEDORA
http://faq.gotomyvnc.com/fom-serve/cache/1.html
vim /etc/sysconfig/vncservers
change commented out thing to 1:username_to_export
su that user if you are not them
start vncserver vncserver :1
set password
stop vncserver vncserver -kill :1
test server script /etc/init.d/vncserver start/stop
if it works set service to start at boot using fedora or mdk service manager.
# Edit ~/.vnc/xstartup
# For KDE, replace "twm &" with "startkde &"
# For Gnome, replace "twm &" with "exec gnome-session &"
# Kill any existing VNC servers with "vncserver -kill :xxx" where xxx is the display number.
# Start a new server
connet using vncviewer ipaddress:1 or whatever you choose to export
SERVICE STATUS
chkconfig
CONFIGURING NTP TIME SERVER
http://linux.cudeso.be/linuxdoc/xntp.php
1. Introduction
XNTP is a timeserver that makes it possible to synchronize your local computer-time with an external time-server. Additionally, you can run your own time-server and let other hosts contact you to synchronize your LAN-time.
First of all, what is NTP? I quote http://www.eecis.udel.edu/~ntp/ntp_spool/html/index.htm
The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks and some provide automatic server discovery using IP multicast.
2. Useful resources
The Network Time Protocol (NTP) Distribution http://www.eecis.udel.edu/~ntp/ntp_spool/html/index.htm
Configuration of NTP http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-config.htm
3. Getting the packages / Install
I've searched for the latest package on http://rpmfind.net. There you can search for the latest RPM for your distribution.
When you're using Red-Hat installation is easy.
rpm -Uvh xntp.rpm
4. Configuration
I'm only going to cover a 'basic' installation. More information is provided on the NTP-configuration webpage.
NTP uses one config file /etc/ntp.conf in which all settings are contained.
Open your favorite editor and edit this file so that it looks somewhat like this :
extract of /etc/ntp.conf
server ntp.myexternalserver.com
restrict default notrust lowpriotrap nopeer nomodify
restrict 123.122.12.1 mask 255.255.255.0 nopeer nomodify
restrict 192.168.1.0 mask 255.255.255.0 # local hosts
restrict 127.0.0.1 mask 255.255.255.255 # local config
That's all there is for a simple, working configuration. In this config file, I connect for the update to ntp.myexternalserver.com.
The restrict settings make sure that I only get an update from my default server (ntp.myexternalserver.com has ip 123.122.12.1) and that only hosts on my LAN can contact my timeserver.
5. Starting and stopping
You can stop the xntp-daemon with the initialisation-scripts located in your inetd.d directory.
Just use xntp start to start the daemon and xntp stop to start the daemon.
One special remark. When I first started the daemon, even when all my regional settings were correct, it gave me the following error-message :
time error 2069.757571 is way too large (set clock manually)
To resolve this, you need to edit the initialisation script and change the line where the daemon gets started.
extract of /etc/inet.d/xntp
case "$1" in
start)
# Adjust time to make life easy for xntpd
if [ -f /etc/ntp/step-tickers ]; then
echo -n "Syncing time for xntpd. "
/usr/sbin/ntpdate -s -b -p 8 -u `cat /etc/ntp/step-tickers`
fi
# Start daemons.
echo -n "Starting xntpd: "
daemon xntpd -A -g
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/xntpd
I have added the -g option to start the daemon. This way, the daemon starts and will synchronize the clock, no matter what time it receives from the external server. Even when the difference between external time and local time is to big (offset to high) the update will take place. This can only happen once. When a second instance occurs, the daemon will exit with an error-code.
6. Configuring the clients
Windows
You can't use your GNU/Linux-timeserver to configure the time-settings on a Windows-machine.
Allthough there are some free tools available that do the trick, I advice you to use the SMB-time protocol with Samba. More information can be found on another page on my site : Tweaky Weaky : Using Samba as a timeserver
GNU/Linux
Easy...just install ntp of xntp and add one line to the configuration file :
server ntp.mytimeserver.com
In this case, mytimeserver.com is the local timeserver on your LAN.
Using Samba as a timeserver
A somewhat 'hidden' feature of Samba is that you can use Samba as a local timeserver for your Windows-clients. Just edit the file /etc/samba/smb.conf and add the line
timeserver = yes
HDPARM OPTIMAL SETINGS
hdparm -c 1 -B 255 -k 1 -M 254 -p 4 -d 1 /dev/hda
GREPING FILES FOR STUFF
grep -i ".*Accept*." /var/log/syslog | less
FINDING A FILE
find / -iname *Accept*
find / -iname *Accept*
find / -iname -mount *Accept*
KERNEL COMPILE BASICS
Kernel 2.4
# make [oldconfig|menuconfig|xconfig]
# make dep
# make bzImage
# make modules
# make modules_install
Kernel 2.6
# make [oldconfig|menuconfig|xconfig]
# make
# make modules_install install
grub
Fallback Position
Because it's altogether too common to produce an unbootable kernel in your first few attempts, you will want to create a "stable" kernel image that you can always boot from. Later, we'll add these to Grub's menu.lst.
cp /vmlinuz /vmlinuz.stable
cp /initrd.img /initrd.stable
If you use separated boot and root partitions, then you shall create stable files in the boot partition as well, or you risk not being able to resort to stable after rebooting:
cp /boot/vmlinuz[-current version number] /boot/vmlinuz.stable
cp /boot/initrd.img[-current version number] /boot/initrd.stable
Now we need to point /vmlinuz to the new kernel and ensure that /initrd.img doesn't exist.
# ln -sf /boot/vmlinuz-2.6.8.1 /vmlinuz
# rm -f /initrd.img (in case a stale symlink is lying around)
Now you must configure Grub to boot the kernels you have available. Here's an example snippet from my /boot/grub/menu.lst:
title=Linux
root (hdX,X)
kernel /vmlinuz root=/dev/hda3
boot
title=Linux Stable
root (hdX,X)
kernel /vmlinuz.stable root=/dev/hda3
initrd /initrd.stable
boot
ALLOW ROOT AND OTHER USERS TO ACCESS X APPpZ
xhost +
su
do normal stuff
SET DATE AND TIME
date MMDDhhmm
date 09262311
CHANGE FLUXBOX BACKGROUND
fbsetbg -C /usr/share/wallpapers/3d_659.jpg
INSTALLING PACKAGES
Slackware:
linuxpackages.net
pkg
pkg -i = install
pkg -u = upgrade
pkg -r = remove
installpkg
removepkg
pkgtool
gslapt
slapt-get slapt-gui
Debian:
add sources to /etc/apt/sources.list
apt-get update
apt-get install
apt-get remove
apt-get upgrade
apt-get dist-upgrade
manual -- dpkg --install packagename
from rpm: alien -di rpm
aptitude
synaptic
Source:
tar -xzvf filename
cd to directory
./configure
make
make install
RPM:
rpm -ihv = install
rpm -Uhv = upgrade
rpm -e = remove
synaptic / yast (if suse)
Mandrake:
urpmi package = install
urpmie package = delete
urpmiq package =gets info
RH:
synaptic
yum
add sources to yum.conf
yum check-update
yum update
yum install
yum search
yum provides so?
yum remove
yum info
VIM SYNTAX HIGHLIGHTING:
:syntax on
copy someones vimrc file.
SCREWED UP NFS PROBLEM
access denied on client
authenticated mount request on server /var/log/messages
add this to servers fstab
none /proc/fs/nfsd nfsd auto,defaults 0 0
has something to do with nfs kernel / nfs modules
BLACKLISTING IPS USING IPTABLES
iptables -A INPUT -s -j drop
-to add to end of rule
iptables -I INPUT -s -j drop
-to add to top of rule
script
---
#!/bin/bash
if [ -f badips.txt ]
then
for BAD_IP in `cat badips.txt`
do
iptables -A INPUT -s $BAD_IP -j DROP
done
else
echo "Can't read badips.txt"
fi
---add bad ips to file. run script at startup. rc.local.
RSYNCING A WEBSITE. MIRRORING
http://www.howtoforge.com/mirroring_with_rsync
--Mirror - test rsync
rsync -avz -e ssh someuser@server1.example.com:/var/www/ /var/www/
source destination.
--Create key on mirror
mkdir /root/rsync
ssh-keygen -t dsa -b 2048 -f /root/rsync/mirror-rsync-key
--Copy key to main server
scp /root/rsync/mirror-rsync-key.pub someuser@server1.example.com:/home/someuser/
--Server add key to authorized keys (as owner of the home dir)
mkdir ~/.ssh
chmod 700 ~/.ssh
mv ~/mirror-rsync-key.pub ~/.ssh/
cd ~/.ssh
touch authorized_keys
chmod 600 authorized_keys
cat mirror-rsync-key.pub >> authorized_keys
ADD THIS TO TOP OF FILE
command="/home/someuser/rsync/checkrsync",from="mirror.example.com",no-port-forwarding,no-X11-forwarding,no-pty
must be fqdn
--Server create an access type list
mkdir ~/rsync
vi ~/rsync/checkrsync
#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\(*)
echo "Rejected"
;;
*\{*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
*\<*)
echo "Rejected"
;;
*\`*)
echo "Rejected"
;;
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac
chmod 700 ~/rsync/checkrsync
--Test rsync on the mirror
rsync -avz --delete --exclude=**/stats --exclude=**/error
--exclude=**/files/pictures -e "ssh -i /root/rsync/mirror-rsync-key"
someuser@server1.example.com:/var/www/* /var/www/
--Add this stuff to a cron job on the mirror.
Test the cron job. Test the mirrored site. Any php scripts that don't
work...copy their setup files outside of the webroot and modify them so they
will work on the mirror server. Should only be one or two vars from one or two
files from each script. Setup a 2nd cron job on the mirror server that will cp
-f these files overtop of the rsynced ones (this will create some upgrade
issues.) Make sure that all files on the mirror are owned by webserver. chown
-Rf apache:apache. MySQL backups add more fun to the mix. Need a cron job
script on the server and on the mirror. Make sure the mysql dump script runs on
the server before the rsync command runs on the miror. Also make sure you add
another cron job to delete the dumped file.
--MYSQL WORKAROUND:
create an account with the same username and password combo on the mirror.
if the server doesn't use 127.0.0.1 as the mysql server add an entry to the
/etc/hosts file for the domain and 127.0.0.1 on the mirror.
SNIPPETS
RSYNC ON MIRROR
rsync -avz --delete -e "ssh -i /root/rsync/mirror-rsync-key" sanchobob@f-t-m.com:/home/sanchobob/f-t-m.com/* /var/www/html/ #sync static files on this machine to the ones on dreamhos
MISC SCRIPT ON MIRROR
cp -f /var/www/setup.php /var/www/html/scry/setup.php
chown -Rf apache:apache /var/www/html
MySQL BACKUP ON SERVER
mysqldump --opt --all-databases -u sanchobob -p -h db.f-t-m.com > test.sql
MySQL RESTORE ON MIRROR
mysql -u root -p < test.sql