Linuxers November 2001

linuxers@mm.ilug-bom.org.in

69 participants
112 discussions

NFS problem....
by Sagar Sule 04 Nov '01

04 Nov '01

hello all, i am installing a Diskless client. i am using a package from Linux Terminal Server Project(www.ltsp.org ). the package did all my configuration. the problem is once the client boots, it downloads the kernel and then says kernel panic. the error is due to NFS root not found. my main problem is even though the /etc/exports file is updated and i restarted the server just to make sure nfs reads the /etc/exports file, the /proc/fs/nfs/xtab file does not have entries for the exported filesystem. exportsfs does show that the file system is exported. any more ideas why this is happening? thanks sagar ===== When you have hit rock bottom, The only way you can go is UP! __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

9 13

[tech] [info] Security in Linux
by Philip S Tellis 04 Nov '01

04 Nov '01

<preamble> Here's something I cooked together for my recent lecture at VJTI. For those of you who do not know, there was a workshop for Engg College Faculty on Linux. Nagarjuna and I were guest lecturers. I spoke on Security and the Kernel, while Nagarjuna introduced linux. Here's the security part. I'll post the kernel part in a separate mail. Feel free to correct bugs. This could also be considered a FAQ from the tcpd wrappers thread. Online version available on my writings page (see sig). NOTE: Heavy dependence on files available either on your machine, or on the net. </preamble> Security in Linux (from the linux security FAQ) Definitions: Linux - the kernel of linux based operating systems, which include the GNU/Linux system Cracker - someone who gains unauthorised access to a system. Not to be confused with a hacker. A hacker is really someone who like to play with computers and write good software. The media often tends to confuse the two. Hackers create, Crackers break. IDS - Intrusion detection system. A system that tries to detect if your system has been compromised, and warns you of it. Tripwire - A kind of IDS that checks whether critical system binaries and configuration files have been modified or not. Firewall - a system that filters traffic moving from outside the network to inside, and vice-versa. Port scanner - a program that checks a host to see which ports are open for external connections. It generally does a blind connect on all ports of a host. Some port scanners can do stealth scanning. Security scanner - a program that checks a host for known vulnerabilities. Security scanners generally try to exploit a vulnerability without causing any harmful effects that would happen in a genuine break in. Some exploits are desined to crash a system, and in these cases, the security scanner may well have to crash a system if it is vulnerable. It is better though to be crashed while scanning your own system, than when someone is actually trying to crash you. Introduction Some of the most common questions asked by people trying to secure their linux systems are: What is security? How can I protect myself from a break-in? How secure should my linux box be? Which is the most secure linux distribution? Security, in a nutshell, is ensuring the Confidentiality, Integrity, and Availability of your systems and network. In short, to protect yourself, you should install the most recent security patches for your distro, turn off unused/unrequired services, run the others through tcpwrappers, and instead of telnet/ftp for remote access, use a secure alternative. The rest of this document will attempt to cover in more detail how to go about securing your linux system. Most important is to decide how secure you need to be. You need to assess the risk to you, and base your security on that. risk=(threat*vulnerability*impact) Threat: the probability of being attacked Vulnerability: how easy is it to break in Impact: what is the cost of recovering from an attack You cannot be 100% secure because there will always be security holes that you either do not know about, or are infeasible to patch. When picking a distribution with security in mind, you should really pick one that has secure default values that you can tweak later. There's no point in installing a system that someone breaks into before you even have a chance to secure it. Distributions like Secure Linux (http://www.trustix.net/) and slinux (http://www.slinux.org/) aim to set secure defaults. Most distros do not have secure defaults because this tends to make the system hard for end users to use. Securing a system is really a trade-off between convenience to your users, and protecting their data. In general, never rely on the default installation of any distribution. Consult the Linux Administrator's Security Guide at http://www.seifried.org/lasg/ for information on how to secure specific distributions. Alternately, OpenBSD, was designed from the ground up as a secure unix, and is probably your best choice for a pure unix implementation. OpenBSD servers and firewalls are extremely secure. A good idea would be to set up a rather open internal network, with tight security between the inside and the outside. That way, local users still have all the convenience, while the system is secure from an external threat. There are still two problems with this approach. If you have legitimate users who need to connect to your system remotely, they would be inconvenienced by your external security. This shouldn't be an issue, as opening up your system to one person, can really open it up to the world. On the inside too, if your users cannot be trusted, then lax internal security could hurt you. Your users could compromise your system by simply not setting good passwords, or leaving their terminals logged in while they are away. There have been cases when crackers have walked into offices, and found system passwords pasted on the office bulletin board for everyone's convenience. Although hitherto unheard of in India, companies abroad have been known to place spies in competitor's companies to steal corporate secrets. There's no use in having the ultimate in network security if your employee is simply going to copy all your secrets onto a floppy and walk out with it. Apart from securing each computer system, and the network as a whole, one also needs to physically secure the entire installation. Firewalls To protect your network, you'd use a firewall between your internal network and the rest of the world. A firewall set up is basically a set of rules that tell the firewall whether a given packet is to be allowed through or not. It can also log information on packets passing through, as well as modify or redirect these packets. Setting up a firewall is very well explained in the linux firewall howto (http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html). In general, you will require to configure IPChains or IPFilter, depending on whether you have a 2.2 or a 2.4 kernel. A firewall is indispensible to the security of a network. Whether it is a dedicated machine or running as a service on another makes a difference. Since a firewall is meant to filter traffic to and from your network, you ideally want it to sit between your network and the rest of the world. Your firewall would have two network interfaces, one of which connects to your network, and the other to the world. Firewall rules decide which packets get from one side to another. A firewall is generally implemented at the kernel level, and can be fast provided it works completely in memory and does not have too many rules. Ideally, you only want your firewall to filter IPs, and let a higher level service handle service based filtering, for example, have tcpd check if anyone is trying to connect to restricted ports on your system, or use a proxy based system to restrict websites that your users may visit. Better logging can be done at these levels, and they are less demanding on the kernel. Services Run only the services that you require and no more. On a desktop system, which you will not access remotely, there should not be any services. Run different levels of services on different machines. You can find out which services are running by using the ps and netstat commands: ps auxfw will show you a tree structure of processes running, while netstat -ap and netstat -altpu will show you which processes are listening on network ports. You may also want to do a port scan of your machine using a tool like nmap, or a security scanner like nessus. Some really unsafe services include rsh, rcp, rexec. Many versions of sendmail and bind have well known security holes. Also disable echo, discard, finger, daytime, chargen and gopher if you don't use them. Wherever possible, use an encrypted protocol rather than a plain text protocol. for example, use ssh instead of telnet/rsh, use scp instead of ftp, use IMAP w/SSL instead of POP3. On a single user system, you should also disable identd, but on a multiuser system, this is a good way of tracking down problem users on your system. You also want to use tcpwrappers to start your services. tcpwrappers are basically an intermediate between inetd and the service that actually serves a connection, like say telnet. Tcpd will check to see if the connecting host is allowed to connect to this service. Different kinds of access control and logging can be done through tcp wrappers. TCPWrappers TCPWrappers, and their associated configuration files /etc/hosts.deny and /etc/hosts.allow help a system administrator set up good access control for his system. First, some background. Most unix systems use what is called a super server to run other servers. The purpose of a superserver is basically to listen on all ports that you want people to connect to, and when a connection is made to that port, it spawns the relevant server. The advantage of such a set up is threefold. Primarily, all these other servers do not need to implement socket io routines. They simply communicate through stdio, and the superserver connects the socket's io streams to stdio before spawning a server. Secondly, we keep our process table small by not running all servers all the time. Only one server runs all the time, and servers that are never required are never started. A server that is required is run only for the duration that it needs to serve a connection. Finally, and really as a consequence of such a set up, we can implement security centrally, and have all servers benefit from it, even if they have no idea that it exists. In fact, these servers know nothing about security at all. Now, in older systems, the superserver was inetd, or the Internet Daemon. In newer systems, it has been replaced with xinetd, which is simply an extended inetd. xinetd can implement security internally, while inetd spawns an external security handler, most commonly tcpd. The configuration files for these servers are usually /etc/inetd.conf and /etc/xinetd.conf, /etc/xinetd.d/*. We aren't concerned too much about the contents of these files, except what services are started by it. Most commonly, the superserver will start services like telnetd, ftpd, rlogind, rshelld, rstatd, fingerd, talkd, ntalkd, etc. Many of these may not be required, and can be stopped. In inetd, this would involve commenting out the relevant line in inetd.conf, while in xinetd, this would involve setting disabled=yes in /etc/xinetd.d/service_name. Disabling these services altogether will cause an inconvenience for your users. For example, you may want to allow nfs connects from certain hosts within your network, but disable it for everyone else. Furthermore, several services have well known exploits, and detecting when someone is trying these is a good early warning system for a possible attack. This is where tcpwrappers, or tcpd (the tcp daemon) as it is known, comes in. TCPWrappers are basically wrappers around your services. It is implemented in two ways, either through the tcp daemon, which starts the requested service after doing access control checks, or through libwrap, which may be linked into the server itself. Either way, the wrappers rely on the files /etc/hosts.{deny,allow}. The full intent and use of tcp wrappers is well documented, and is shipped with all linux distributions. It can be found in /usr/doc/tcp_wrappers/* or /usr/share/doc/tcp_wrappers/*. Here I will outline the most important usage. How exactly does tcpd come in to play? Instead of directly starting the server, inetd can start tcpd, and tell tcpd to start the correct server after performing any checks, etc. that it wants. If one opens /etc/inetd.conf, one will find against the telnet and ftp lines that the daemon to be spawned is tcpd with in.telned/in.ftpd as arguments. telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd The other values on the line aren't important for that discussion, and you'll figure them out soon enough. Now, in execve parlance, the first argument passed in the argument vector corresponds to argv[0], i.e., the name that the program should call itself. tcpd takes this hint, and calls itself in.telnetd (which is what will show up if you list running processes). It performs its checks, and then execs in.telnetd, passing all file descriptors on. Thus, we have tcpd, which has a single access control file, doing checks for most daemons. Further more, since tcpd comes into the picture only while a connection is being estabilished, and leaves the scene thereafter, there is no overhead involved (except for that during checking, which is what we want). Now, not all servers are started through inetd. Many, like sendmail, apache, and sshd, run as standalone servers. These servers can have tcpd compiled into them using libwrap.a and tcpd.h. They will then automatically check with hosts.allow and hosts.deny. Now all these options must be selected while compiling tcpd and libwrap, but the defaults are decently secure anyway. To check the configuration of your tcpd wrappers, use /sbin/tcpdchk. Give it the -v flag for more information. The hosts.{deny,allow} files Wietse Venema, the creator of tcpd, also developed a 'language' for specifying the access control rules that govern who can use which service. These rules are specified in hosts.allow and hosts.deny. The normal strategy is to deny all connections, and explicitly allow only services that you want people connecting to. For eg: your hosts.deny would read like: ALL: ALL This means deny all services to requests from all addresses. Remember that hosts.allow is checked first, then hosts.deny. The first rule that matches is applied, so basically, if a match is not found in hosts.allow, it will be denied. If hosts.deny is empty or missing, then the default is to grant access. The extended acl language also allows deny rules to be specified in hosts.allow, so you really only have to manipulate a single file. Rather than go into the details of all possible configurations, I'll just paste my own hosts.allow file here, and explain it line by line. Intrusion Detection Intrusion Detection is the ability to detect people trying to compromise your system. Intrusion detection is divided into two main categories, host based, and network based. Basically, if you use a single host to monitor itself, you are using a host based IDS, and if you use a single host to monitor your entire network, you are using a network based IDS. Most home users would use a host based IDS, while universities and offices would have a network based IDS. There are many Intrusion Detection Systems (IDS) for linux, the most popular, for host based and network based is snort. Snort is available from http://www.clark.net/~roesch/security.html. Others are portsentry (http://www.psionic.com/abacus/portsentry/) and lids - the Linux Intrusion detection system (http://www.lids.org). Going into the details of each of these is beyond the scope of this document, but all tools have very good documentation. In addition to an IDS, you would also want to use an Integrity checker, which basically makes sure that none of your binaries and critical configuration files have been modified. When a cracker compromises a system, the first thing he's likely to do, is create a backdoor for himself. There have been many instances where critical binaries like the ssh daemon have been replaced with trojaned versions that capture passwords and mail them back to the cracker. This then gives the attacker free access to the system, even if the original hole is plugged. Tools like tripwire (http://www.tripwire.com/), AIDE (http://www.cs.tut.fi/~rammer/aide.html), and FreeVeracity (http://www.freeveracity.com/) check the integrity of your binaries. Of the above, FreeVeracity is reputed to be very easy to set up and use. Typically, one would create an integrity database when the system is installed, and update it whenever new binaries are installed. The database should always be backed up onto read-only media like a CD. The checker should be run everyday through a cron tab entry, to check all critical files. If the tool finds any discrepancies, it sends a mail to a pre-defined email address. The Integrity Checker should be configured well to prevent false alarms which makes it a hindrance more than an aide. So, how do you know whether you've been compromised or not? CERT has released an advisory to help you identify if an intruder is on your system. The complete document is available at http://www.cert.org/tech_tips/intruder_detection_checklist.html. In short though: - Check your log files, - Look for setuid/setgid files, especially if they are owned by root - Check what your integrity checker has to say about your system binaries - Check for packet sniffers which may or may not be running - If you didn't install it, it shouldn't be there - Check your crontabs and at queues. - Check for services that shouldn't be running on your system - Check /etc/passwd for new accounts/inactive accounts that have suddenly become active Full details, including how to do the above are listed in the abovementioned document. So what do you do once you know that you've been compromised? Well, the first thing is not to panic. It is very important not to disturb any trails that the cracker has left behind, as these can all be used to detect who the attacker was, and even exactly what he did. Very importantly, don't touch anything on the system. Step one is to disconnect the machine from the network. This will not only prevent further attacks, it will also prevent the attacker from covering up his trails if he finds out that he's been caught. To prevent any data from being changed, you should also mount your file systems read-only. Copy all your log files out to another system, or a floppy disk, where you can examine them safely. Analyse the saved data to determine what the attacker did to break in and what he did after that. Restore your system from known pre-compromise backups. Again, CERT has published a white paper on recovering from an attack. It is available at http://www.cert.org/tech_tips/win-UNIX-system_compromise.html Testing Security There are many commercial organisations that will test the security of your system for you. These are costly though. A cheaper alternative may be to use one of the many web based security scanners to test your system. http://www.hackerwhacker.com http://maxvision.net/#free http://www.grc.com http://privacy.net/analyze http://www.secure-me.net/ You shouldn't trust what they tell you, but it will be interesting to monitor your logs and network while an attack is in progress. You can also test yourself by using your own port scanner and security scanners. Nmap (http://www.insecure.org/nmap/) is the most popular and widely used port scanner around, both by black hats and white hats. It can also determine which OS you use, which is what a cracker would need to know to find OS specific vulnerabilities. If nmap can't figure out which OS you're using, that could slow down your attacker for a while. SATAN (Security Analysis Tool for Auditing Networks) that was developed by Dan Farmer of Sun Microsystems, and Wietse Venema (of tcpd fame) from Eindhoven University of Technology, Netherlands, was developed with the specific intent of doing everything that an attacker would do to gain unauthorised access. This tool has been replaced with a next generation version called SAINT (http://www.wwdsi.com/saint/index.html) Nessus (http://www.nessus.org/intro.html) has a plugin based architecture. Vulnerabilities checks are written as plugins, which means that you can check for new holes as they become publicly known, without upgrading your entire binary. Viruses and Trojans The real question in this section is, is linux vulnerable to viruses and trojans. Practically, no. Technically though, it is possible. Due to the design of Linux, it is difficult for viruses to spread far within a system, as they are confined to infecting the user space of the user who executes them. Of course, this is a problem if infected files are launched by root, but as a security conscious individual, you wouldn't be running untrusted files as root, would you? It is theoretically possible for a virus launched by a regular user to escalate its privileges using system exploits; however, a virus with this capability would be quite sizable, and difficult to write. As of this date, few viruses have actually been discovered for Linux, and the ones that have been discovered aren't worth losing sleep over. This will undoubtedly change with time. Worms like l10n and Top Ramen only worked because the systems were insecure to begin with. An insecure ftpd/rstatd was used to automatically gain access to machines, and use them as further launching grounds. Viruses do exist for Linux, but are probably the least significant threat you face. On the other hand, Linux is definitely vulnerable to trojans. A trojan is a malicious program that masquerades as a legitimate application. Unlike viruses, they do not self replicate, but instead, their primary purpose is (usually) to allow an attacker remote access to your computer or its resources. Sometimes, users can be tricked into downloading and installing trojans onto their own computers, but more commonly, trojans are installed by an intruder to allow him future access to your box. Trojans often come packaged as "root kits". A "root kit" is a set of trojaned system applications to help mask a compromise. A root kit will usually include trojaned versions of ps, getty, passwd, At this point in time, virus Scanners for Linux are aimed at detecting and disinfecting data served to Windows hosts by a Linux file/mailserver. This can be useful to help stop the spread of viruses among local, non-Unix machines. Due to the lack of viruses for Linux, there are presently no scanners to detect viruses within the Linux OS, or its applications. Trojans present a greater threat to the Linux OS itself than do viruses, and can be detected by regularly verifying the integrity of your binaries, or by using a rootkitdetector. Trojan Detectors: Chkrootkit: (http://www.chkrootkit.org/) - Checks Linux system for evidence of having been rootkitted. Root Kit Detector: (http://www.vancouver-webpages.com/rkdet/) - A daemon that alerts you if someone atttempts to rootkit you. Virus Scanners for Linux File Servers: AMaViS: (http://www.amavis.org/amavis.html) - A sendmail plugin that scans incoming mmail for viruses. AntiVir for Linux: (http://www.hbedv.com/) - Scans incoming mail and ftp for virusess. Interscan Viruswall: (http://www.antivirus.com/products/isvw/) - A Firewall-1 add-on that scans ftp, htttp, and smtp for viruses. Sophos AntiVirus: (http://www.sophos.com/products/antivirus/savunix.html) - Checks shares, mail attachments, ftp, etc. for viruses. Finally, a system administrator must understand that security is a process. You need to keep yourself up to date with all the latest security news. Subscribe to the securityfocus, cert, and other security related mailing lists. Stick to the comp.os.linux.security newsgroup. That's also a good place to post your queries - if they haven't already been answered. Monitor your log files regularly. Use remote logging to protect against modified log files. Protect your system binaries. Keep them on read-only partitions if required. The only way to protect yourself completely, is to be aware of what is happening all the time. References: The comp.os.linux.security faq The linux security howto (http://www.linuxsecurity.com/docs/Security-HOWTO/) The linux administrator's security guide (http://www.seifried.org/lasg/) The linux firewall and proxy server howto (http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html) CERT advisories (http://www.cert.org/) Security Focus (http://www.securityfocus.com/) -- Save yourself! Reboot in 5 seconds! Visit my webpage at http://www.ncst.ernet.in/~philip/ Read my writings at http://www.ncst.ernet.in/~philip/writings/ MSN philiptellis Yahoo! philiptellis AIM philiptellis ICQ 129711328

5 7

[OT] gnu@db.ilug-bom.org.in - Mail bounced back
by Amish Mehta 04 Nov '01

04 Nov '01

Hi, Somebody(Nagarjuna?) please check out. It was regarding Cyberoam authentication client. Probably $w macro problem. Missing Cw or Fw entry. ----- Transcript of session follows ----- 553 5.3.5 db.ilug-bom.org.in. config error: mail loops back to me (MX problem?) 554 5.3.5 <gnu(a)db.ilug-bom.org.in>... Local configuration error Amish.

1 0

Re: [ILUG-BOM] cyberoam client?
by Amish Mehta 04 Nov '01

04 Nov '01

Hi, Nagarjuna G. wrote: > >On Sun, 4 Nov 2001, Amish Mehta wrote: >->I could not upload files to Sourceforge because of some reason. >-> Okay I have released a tar.gz file on sourceforge. > > Amish, if you want to upload on our own space( > db.ilug-bom.org.in) send the files to gnu(a)db.ilug-bom.org.in. > If you want a project page we can provide one. Okay thanks Nagarjuna, I have done this too. Amish.

1 0

Re: [ILUG-BOM] cyberoam client?
by Amish Mehta 04 Nov '01

04 Nov '01

Hi Chandrashekhar, Please goto http://briefcase.yahoo.com/amishmm and search there. I could not upload files to Sourceforge because of some reason. Amish.

2 1

Anyone have staroffice 6.0 beta
by Anand 04 Nov '01

04 Nov '01

Hi, Does anyone have staroffice 6.0 beta, which can be burnt and used by me. Anand -- ------------------------------------------------------------------------ Visit www.smbd.org <http://www.smbd.org> for Free Tutorials, Source Codes and Other stuff. ------------------------------------------------------------------------

3 2

iptables error
by Satpal Ramgadia 04 Nov '01

04 Nov '01

Hiee i installed iptables but when ever i restarts the machine i getting errors -A command not found -A command not found -A command not found for each rule i set it shows command not found what is this i couldnt understand i think it couldnt find out the path i stored iptables in /etc/sysconfig n removed ipchains from there so it will take iptables from there n will load but failed to load is the path wrong if the path is wrong where n how to give the path of iptables to load every time machine starts Thanx Satpal please help me out of this prob Satpal __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

2 1

[Hurd Orientation]
by Pankaj Jangid 04 Nov '01

04 Nov '01

I recently joined a hurd mailing list. I received this mail in a that list. I want it to share with you. It is a good small introduction to HURD OS. Welcome to the Hurd =================== Welcome to the Hurd. This email is automatically sent at the begining of each month to the help-hurd(a)gnu.org and debian-hurd(a)lists.debian.org mailing lists. This message is intended for a quick orientation to new users. What is the Hurd? ----------------- The Hurd is GNU's Multiserver Microkernel operating system. It is designed with the intention of fixing many of the flaws in *nix. What are these flaws? The arbitrary limits that it imposes on the user: there is not a whole lot that a user can do without special privileges. Consider an NFS filesystem. Only root can mount this on a traditional *nix system. Why is this? It is not that NFS accesses anything dangerous, at least, it is no more dangerous than ftp. However, as a portion of the NFS code lives in the kernel, this presents a potential security problem. In the Hurd, a user can transparently mount a NFS filesystem directly into their home directory without affecting the security of the system as a whole. And this is only the tip of the iceberg. Getting Started --------------- Installation Guides can be found at the following locations: http://web.walfield.org/papers/hurd-installation-guide/ You can find out about ISO images at: http://www.debian.org/ports/hurd/hurd-cd They come with a modified version of the Debian boot floppies making installation relatively simple. GNU Mach uses the drivers found in the Linux 2.0.x kernel. Note, there is no support for PCMCIA. Here is a HCL: http://www.urbanophile.com/arenn/hacking/hurd/hurd-hardware.html Mailing Lists: - bug-hurd(a)gnu.org: Hurd and Mach development. - help-hurd(a)gnu.org: General Hurd questions. - web-hurd(a)gnu.org: Maintenance of the hurd webpages at http://hurd.gnu.org. - debian-hurd(a)lists.debian.org: All things related to Debian GNU/Hurd (especially porting issues). Subscribe in the usual fashion. The Hurd FAQ: http://web.walfield.org/papers/hurd-faq/ Contributions ------------- A common question is: how can I contribute? There are many tasks that need to be done: - Help update the web pages at hurd.gnu.org. Contact web-hurd(a)gnu.org. - Write documentation. - Port applications. Contact debian-hurd(a)lists.debian.org. Look at http://people.debian.org/~jbailey/turtle/group/Debian/index.html - Write code. Contact bug-hurd(a)gnu.org. Look at: http://www.debian.org/ports/hurd/hurd-devel-tasks, <hurd>/tasks and <hurd>/TODO - Send feedback. This is, of course, the most important task of all: Help us help others. Happy Hacking. -- Pankaj Jangid National Centre for Software Technology Alt-Email-ID : pankaj(a)ncst.ernet.in Yahoo-msnger : pankaj_jangid GPG Public Key : http://ashoka.ncst.ernet.in/~pankaj/gpg.txt

1 0

[Commercial] Computer Books for Sale.
by akshaysalkar 04 Nov '01

04 Nov '01

Does any 1 want Computer/Linux Books at a reasonable rate (ie.20%-22%off the normal price) Books in good condition. (Costs after Discount) 1) CGI Programming with Perl - Gundavaran - Rs. 250 - O'Rielly 2) Programming Perl 3/e - Larry Wall - Rs. 450 - O'Rielly 3) Data Structures using C & C++ - Rs. 150 - Prentice Hall 4) Teach yourself HTML4 in 24 hours - Rs. 100 - Techmedia 5) Mastering Foxpro 2.5 Special Edition - Rs. 200 - BPB 6) Begining Linux Programming - Mathews - Rs.450 - Wrox 7) Teach yourself Shell Programming in 24 hours - Veeraghavan - Rs.125 - Techmedia 8) Building Linux Clusters - David Spector - Rs.250 - O'Rielly any wanting any of the above books plz. contact me at email : akshaysalkar(a)indiatimes.com akshay. Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

1 0

questions
by abhijeet 03 Nov '01

03 Nov '01

hi this is on the ongoin' topic of content quality on the list. here is a link - perhaps known to many - which would help. this howto would help people to ask questions and perhaps articulate Philip's thoughts on the subject better.......- no offence meant...Philip's a good writer- i found it on eric raymond's home page. http://hurkle.thyrsus.com/~esr/faqs/smart-questions.html ciao abhijeet

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Linuxers November 2001