What are the best packages to help me access an MS-SQL server from a Linux system? I've noticed that some versions of Sybase and other public domain software can do this. I am trying to find the best public domain software and would like to test at least three packages other than Sybase.
What are the best packages to help me access an MS-SQL server from a Linux system? I’ve noticed that some versions of Sybase and other public domain software can do this. I am trying to find the best public domain software and would like to test at least three packages other than Sybase.
There are several Linux programs that are capable of editing databases, a large number of which will work with a variety of different back-ends, including Microsoft SQL Server.
The easiest way to set this up is probably to access SQL server via a generic ODBC interface, found on many client programs. A quick search on http://www.freshmeat.net yielded the following libraries and client programs for ODBC databases (there are several more as well):
A popular Web-based administration program exists (http://phpwizard.net/projects/phpMyAdmin/index.html) for MySQL and has been ported to PostgreSQL as well. If you have a little time, you might try editing PhpMyAdmin for ODBC.
If you’re used to the high-end and ease-of-use features of the more professional database modeling tools, you may find that the free tools that are currently available aren’t quite mature enough yet. To that end, perhaps contributing to an existing tool to help build it out is the answer.
When running in an internal environment, say 192.168.x.x, I don’t need DNS, though services such as FTP perform DNS lookups on any incoming connection. This takes a few annoying seconds before timing out and letting you connect. How do you disable the DNS lookups that are done at connect time?
First of all, if this is a permanent internal network, especially a large one, I’d recommend setting up nameservice just as a matter of protocol. It isn’t that hard and may end up saving some time and headache should you later need the capability.
That said, assuming you don’t want nameservice, or this setup is temporary enough to require simplicity and speed, there are a couple of things that you can do to help solve some of your timeout problems.
Different programs react in different ways to nameservice changes, so you may have to experiment with several different options.
First, try simply removing all nameserver entries from /etc/resolv.conf. Wrong entries in this file are definitely worse than none at all, as the lookups will have to timeout on every nameserver before concluding that something cannot be resolved.
Next, there are some C function calls which use configuration from /etc/ nsswitch.conf. Find the line that looks like this:
and remove the dns entry. This should tell glibc not to use DNS for name lookups.
If all else fails, you can guarantee success by either giving machines a valid name entry or an authoritative denial. This certainly shouldn’t be necessary for any behaving DNS clients, but should work in all cases. Adding an /etc/hosts entry for all machines is one solution, as is pointing to a dummy nameserver that will answer an authoritative “no” to all requests (although this is really as much work as simply setting up a real nameserver as suggested above.)
I’ve been running a patched Linux 2.2 kernel with reiserfs and would like to upgrade to the 2.4 kernel. I’ve heard that the reiserfs code in the 2.4 kernel uses a different format, but the reiserfs Web site doesn’t discuss upgrading. What do I do?
The 2.4 kernel contains reiserfs 3.6.x, and the 2.2 series patches were version 3.5.x.
reiserfs 3.6.x will indeed mount older reiserfs partitions using the older format. However, you will not be able to take advantage of newer features, including file sizes over 4 GB.
If you mount the partition with the -o conv option using 3.6.x, the partition will be converted to the new format. You’ll only need to do this once; you won’t be able to convert back to the old format. This means that if you ever want to downgrade to the 2.2 kernel series for some reason, you won’t be able to mount this converted partition.
As always, if you have any way to back up the partition, I’d recommend doing that before the upgrade. It just makes sense.
There was also filesystem corruption in early 2.4 kernels. This has now been fixed, but be sure to use the latest kernel and check for any patches on the reiserfs Web site before upgrading.
For the most up-to-date information, try perusing the reiserfs development mailing list or visiting the Web site at http://www.reiserfs.org/.
I need to run more than one Apache configuration, but my package manager doesn’t seem to allow me to install more than once. Can I run multiple Apache configs on one machine?
Yes, but you’ll need to run them on different IP addresses or different ports. Name-based virtual hosts will only work across one Apache server config.
First make sure that you need additional Apache configurations. Most everything can be done in one httpd. conf file with multiple virtualhost entries specifying different configuration options. This file may become large and unwieldy, but will likely be better than maintaining two Apache server implementations on your machine.
You may have reason to run more than one Apache installation, though. If you must run different versions of the server software itself (such as 1.3.x and 2.0.x), you will obviously need to install more than one Web server package. The preferred way is to edit the packages themselves and set up an installation in an alternate location that does not conflict with other versions of the software. This requires some knowledge of building packages but will be the cleanest way to do this, as you will retain many of the benefits of package management, including better uninstall and upgrade capabilities.
Alternatively, you may choose to perform a source installation to two (or more) different directories. This can be easily accomplished by using the –prefix option for the configure script, as illustrated in Figure One.
Listing One: Apache Source Installation
./configure –other-options –prefix=/opt/apache-legacy/
make; make install
./configure –other-options –prefix=/opt/apache-testing/
make; make install
The Filesystem Hierarchy Standard (FHS, http://www.pathname.com/fhs/) recommends use of the /opt, /etc/ opt and /var/opt directories for this type of thing. I’d probably just perform a default install in /opt for this and perhaps symlink /var/opt for logfiles if I wanted these on a /var filesystem. Others may choose to use a /usr/local/ scheme for this, although I maintain that /usr/local/ is not the best structure.
It is also possible that you’ll need to use different configuration files, but you will be able to use the same Apache installation. This would be the case if you required incompatible modules or conflicting options.
Before you do this, however, please look into simply making the configuration changes in virtualhosts, as it will save you time and pain later when you wish to upgrade.
If you do decide to proceed, you’ll want Apache configured and installed with as many dynamic modules as is possible, since you can pick and choose these in each httpd.conf file.
1. Create an /etc/apache-specific/ and a /var/apache-specific/ directory for each config you’ll need.
2. Copy configuration files into the /etc/apache-specific/ directories.
3. Create a copy of apachectl for each config. Place this in a bin directory that you wish to use.
4. Modify the apachectl-specific files for each config. There are PIDFILE and HTTPD environment variables that need to be edited appropriately.
You’ll also need to add config options to the HTTPD line. Specifically, the -d serverroot and -f configfile options will be necessary to differentiate the different configurations. Read the apache/httpd man page if you have questions about this.
5. Modify/Add init.d entries as appropriate for each config, assuming you want these servers to begin on startup.
6. Modify each /etc/apache-specific/httpd.conf file for directory information specific to each server instance. You’ll also be able to make all module loading changes and other necessary configuration changes. Be sure that each of these uses a different IP address or listening port. Also be sure that log files are kept separately in each /var/apache-specific/ (or /var/log) directory.
You should now be able to start and stop each of these Apache implementations separately, each one having its own config file and var directory. You will also have the added advantage of continued use of your package manager for upgrades, and upgrades of a single server rather than going through multiple installs.
Drew Streib is a coder, admin, and writer with VA Linux Systems. He can be reached at email@example.com.