zhao-sun.com

• go http://www.ibiblio.org/pub/Linux/X11/fonts/”, and download xfstt-1.1.tar.gz — xfstt server program

• install xfstt, type in
  
  make && make install

• Create a writeable directory /usr/share/fonts/truetype, copy some truetype *.ttf files (in windows 98, under c:\windows\fonts), or create soflinks to truetype directories in there, then run
  
  xfstt –sync

• Start xfstt in the background
  
  xfstt &

• Tell your X11 server about the new font service
  
  xset fp+ unix/:7101
  
  or add the new fontpath to the X11 config file
  
  FontPath “unix/:7101”

• specifying the appropriate X resources in your .Xdefaults file:
  
  Netscape*documentFonts.sizeIncrement: 20
  
  Netscape*documentFonts.xResolution*iso-8859-1: 100
  
  Netscape*documentFonts.yResolution*iso-8859-1: 100

• create a new file owned by root, put it into a directory, say /etc/rc.d
  
  #!/bin/bash
  
  /usr/X11R6/bin/xfstt –sync
  
  /usr/X11R6/bin/xfstt &

• add the following lines in the file /etc/inittab
  
  # Run xfstt_start in runlevel 5
  
  # xfstt_start start xfstt
  
  xf:5:wait:/etc/rc.d/xfstt_start
  

• add the following lines in the .cshrc (if using csh or tcsh)

  
  # true type font
  
  xset fp+ unix/:7101

• for kde 2.1, /etc/X11/XF86Config file need to be edited as: (two lines have to be in this order)
  
  FontPath “unix/:-1”
  
  FontPath “/usr/share/fonts/truetype/”

  Or you can go to Font HOWTO page to find more information.

• as root, create a new user group by running “groupadd [-g gid] groupname”.

• edit /etc/passwd and /etc/group two files.

• go kde.org, and download “qt, kdesupport, kdelibs, kdebase, kdeutil” rpm package. All the others are optional.
  

• for each package, by the order in Step 1, run “rpm -Uvh –nodeps –force PACKAGE_NAME”.
  

• update the package pam (Pluggable Authentication Modules) under /etc/pam.d/kde. (I copied it from /etc/pam.d/gdm.)

• as root, edit /etc/xinetd.d/telnet. set “disable = no”.

• under the user home directory, put .rhosts there, and set it to mode 600. One example line in .rhosts file can be “hostanem userid”.

• check /etc/xinetd.conf file, /etc/xinetd.d/rlogin and /usr/sbin/in.rlogind are there.

• As root, go single user:
  telinit 1

• Partition new disk with tool, such as fdisk.

• Format new hard drive partition(s):

  mkfs -t ext2 /dev/hdc1

  Provide device and filesystem as appropriate for your system or your
  choice.

• Mount new hard drive:

  mount -t ext2 /dev/hdc1 /mnt/newdisc

• Edit /etc/fstab to include new mount point:

  /dev/hdc1 /mnt/newdisc ext2 defaults 1 2

• Or you can go to http://www.tldp.org/HOWTO/mini/Hard-Disk-Upgrade/ to find more information.

• Or these are two messages in Google Groups: MSG1 and MSG2

• as root, create the source direcory, and run “cvs init”. This will create CVSROOT directory.

• set the correct value to CVSROOT inside your login batch
  file, such as in my .cshrc, I say “setenv CVSROOT /src/master”.

• for importing into the source repository, first go the directory with the sources, and run “cvs import test yoyo start”.

• for checking out, after set correct CVSROOT, do “cvs update -d” or “cvs co [source module name]”.

• for create a personal branch, do “cvs rtag -b [branch name] [souecr module name]”, and then run “cvs update -r [branch name]”.

  Or you can go to cvs document page to take a look.
  

Tag and Create a new branch

When your mainline is ready to ship, tag it. You have to do this anyway to remember what you shipped.
• cd an_up_to_date_working_copy
  
• cvs tag main_1_0

  Create a branch and put the working copy on it.

• cvs tag -r main_1_0 -b B_1_0_branch
  
• cvs update -r B_1_0_branch

  Make the changes for customer B, and commit them as you go. Because your working copy has a sticky tag from the “update -r B_1_0_branch”, your commits go to that branch instead of the trunk.

  When your branch is good, tag it too.

• cvs tag B_1_0

  You can now go to a clean directory and export revisions main_1_0 and B_1_0 for shipping.

  Return to your working copy and put it back on the trunk.

• cvs update -A

  All your “B” changes are gone, you are back to the mainline. Proceed with normal development. When your mainline is ready to ship again, tag it.

• cvs tag main_1_1

  Now the fun part: you create a new branch for customer B and recreate all the changes you made the first time.

• cvs tag -r main_1_1 -b B_1_1_branch
  
• cvs update -r B_1_1_branch
  
• cvs update -j main_1_0 -j B_1_0
  
• # fix conflicts
  
• cvs commit

  The “update -j -j” does most of the work for you, but it’s not foolproof so you have to manually inspect and test your sources. You’ll be surprised how little damage you have to fix. When you’re happy, tag the tip of your new B branch.

• cvs tag B_1_1
  
• cvs update -A

  The process repeats after the second release. Tag, create new branch, merge the previous branch to it. You have to be very clear about the use of those branches: all development happens on the trunk, the “B” branches are *only* for customer-specific variants. You never merge these branches back to the trunk.

  (In truth, you should also have bugfix branches for the normal code you ship, but that’s an easier pattern to master than the stepladder of branches I just described. Stick to the hard stuff for now… 🙂
  

• on Linux DHCP client machine, run “dhcpcd -k” to send DHCP_RELEASE signal. run “dhcpcd” or “dhcpcd -h hostname” to get an ip from DHCP server

• on Linux DHCP server machine, run “cp /usr/share/doc/dhcp-/dhcpd.conf.sample /etc/dhcpd.conf”

• “edit /etc/dhcpd.conf”

• “touch /var/lib/dhcp/dhcpd.leases”

• “/usr/sbin/dhcpd eth1”

• for more detailed information, try DHCP Server Help

• on the Linux server machine, edit /etc/exports, adding a line “/vol shanghai(rw) chuangchun(rw)” at the end; and run “/etc/init.d/nfs restart”

• or on the Linux server machine, following the steps as stated here – NFS Howto

• on the client machine, (can be a Unix or a Linux system), run “mount (SERVER_IP_ADDRESS):(SHARE_DIRECTORY) (LOCAL_SHARE_DIRECTORY)”; or on the Linux client machine, to mount file systems at boot time, edit /etc/fstab, adding a line “wenji:/opt
  /mnt/shared/opt nfs rw 0 0” at
  the end.
  

I am running samba on redhat linux 6.0. Then I tried to use samba to talk to another computer running both Windows 2000 and Windows 98.

• go http://www.samba.org,
  and download the most updated stable version of samba for my redhat linux 6.0 system

• untar the download file. If it is in rpm format, use “rpm –install” or “rpm –upgrade” to install the samba package.

• create a file, called /sbin/startsmb, and make it executable
  
  #!/bin/sh
  
  /usr/sbin/smbd -D
  
  /usr/sbin/nmbd -D -G SIEGE
  
  (the last word “SIEGE” is your Workgroup name. and if you want to start samba automatically at boot time, create two soft links under /etc/rc.d/init.d and under /etc/rc.d/rc5.d)

• configure the /etc/smb.conf file.

• run /sbin/startsmb, that’s almost it on linux side

• On Both Windows 2000 and Windows 98 systems, set the computer name and workgroup name.

• I also installed NetBEUI Protocol on the network card talking to my linux box. I know that’s a must for Windows 98, but not sure for Windows 2000

• On Windows 2000, go Control Panel –> Users and Passwords –> Advanced –> Advanced –> Users –> Guest –> Properties –> unset “Account is disabled”, which make guest accout enabled

• on Windows 2000, I have also added a Windows component, Internet Information Services (IIS). Again, I don’t know whether this is a must or not. However, after installing IIS, I can ftp to my Windows 2000 now.

• So, that’s it. Now, from my linux box, I can see all the shared files and use shared printer on my Windows system. From my Windows system, I can see all the shared files defined in /etc/smb.conf. I can just click the files and edit them or winzip them directly on Windows. People won’t notice the files are on another computer. Is that beauty? ENJOY!
  

• on the server machine, run “xhost +(CLIENT_IP_ADDRESS)”.

• on the client machine, run “setenv DISPLAY (SERVER_IP_ADDRESS):0”.

• on the client machine, run the program.