KCLUG

kclug@kclug.org

2 participants
3242 discussions

Re: Databases
by James Sissel 10 Mar '05

10 Mar '05

> >>> There used to be a series of PC databases - DB > II, DB III, DB IV. > >>> Whatever happened to those? Better dBase products came out that were cheaper (MUCH cheaper). > What other databases have died anybody? It's not dead but it might as well be. The best damn PC based database ever written. FoxPro! They were well ahead of their time. And then Micro$oft bought them out. They came out with a very buggy version 2.5 and then charged you $20 for the patches which they called version 2.6. Version 3 was a piece of crap. Version 4 went ???? because the next version was version 5. Starting Version 3 good old Micro$oft killed the dbase language and put in their Visual Basic (gag, choke). Of course Micro$oft already had their "database" product called Access. IMHO, the biggest piece of coding shit ever written. So they aren't pushing FoxPro. I've unfortunately used Access from Version 2.0 up to now Version 2003 (when are we going to stop this naming for the year BS?) You'd think they could get it right in that amount of time. I pray for the day that Micro$oft goes under.

1 0

RE: Oracle
by Brian Densmore 09 Mar '05

09 Mar '05

> -----Original Message----- > From: Frank Wiles > > ... > > Oracle is really only necessary if you need to run a HUGE database > across multiple servers. Otherwise, it's just a waste of money. > Unless you get it for free. ;') But really that comparison is hardly just. Oracle is not cheap, but there is a lot more to Oracle than just the RDB, and there are other factors to consider than just size and distribution. However, I'd probably not recommend Oracle for a new implementation if MySQL or PostgreSQL could handle the data and load expected of the implementation. Including future needs. No sense in going with MySQL if you are expecting to get the outsourcing contract for Wal-Mart's inventory database. ;')

7 7

RE: Oracle
by Brian Densmore 08 Mar '05

08 Mar '05

> -----Original Message----- > From: Dave Hull > > Quoting Brian Densmore <>: > > > I recently acquired an older version of Oracle (v. 8i). > > I was wondering if it might be possible to load it on > > a Linux box? Or if I need to break out the NT cd's? > > I haven't even opened the shrink-wrap yet. I was thinking > > about using it at home for projects, or possibly on an > > alternate PC for access by my webserver. > > You can download Oracle from Oracle for free and use it for > development > (non-production) work. Right, I knew that, but this is a fullblown shrink-wrapped enterprise level version with all the bells and whistles and documents. Which is a bit different than the download version (which I ordered from Oracle way back) on a CD from Oracle, I think I also have the 9i download version on CD. > If you're just wanting to gain some > experience with it. > I believe I had installed 8i on Red Hat a few years back, but > I had to jump > through some hoops. > Well, I've been wanting to play with some databases for a while, but I have some real projects I will be working on also. Thanks, Brian

4 5

RE: Oracle
by Brian Densmore 08 Mar '05

08 Mar '05

I plan on using MySQL and probably PostgreSQL, too. But Oracle has lots of nice gui tools for doing design work and such. Plus I have several books on Oracle that have not even been read yet. So it's a learning thing, even though the final implementation may wind up being in MySQL or PostgreSQL, for licensing and distribution purposes. Which would also give me some opportunity to port from Oracle to other databases and learn the ins and outs of such portations. I have several server capable PCs laying around and plenty of space left on the home LAN. So it's an ideal project. As far as the 9i, yes I believe both the 8i and 9i download versions I have are personal versions. I do have one specifically for Linux. So you think Oracle is a doomed application? Does that also include: SQL Server, DB2, et al? I tend to agree, but I doubt they will entirely disappear, for a long time, kind of like COBOL. There will continue to be a number of older shops still using them far into the future, but the market will shift towards the OSS RDBMs. So, portation skills will be useful. Just looking for gotchas to look out for before diving in. Thanks, Brian > -----Original Message----- > From: Dave Hull > > Quoting Brian Densmore <>: > > > Right, I knew that, but this is a fullblown shrink-wrapped > enterprise level > > version with all the bells and whistles and documents. > Which is a bit > > different than the download version (which I ordered from > Oracle way back) on > > a CD from Oracle, I think I also have the 9i download version on CD. > > According to Oracle's web site, the versions available for > download are the full > versions. Even the documentation is available for download. > We've been using the > downloaded versions where I work in a production environment > (yes we have the > licenses) for a few years and I can tell you they are > identical to the packaged > versions we received in the mail after we bought the licenses. > > I prefer to grab the latest ISOs from Oracle though because > they have the most > recent patchsets applied. > > If you got 9i on a single CD, you must have a "personal" > version or something > because 9i requires three CDs... 10G requires only one CD, or > so I was told by > our Oracle rep. > > > Well, I've been wanting to play with some databases for a > while, but I have > > some real projects I will be working on also. > > Good luck. I usually reach for MySQL first. We've been using > the 4.1.2 version > with full support for referential integrity and transactions > with great success > in production for nearly a year with only one strange bug > that has recently been > addressed by the developers. > > MySQL is much easier to manage than Oracle, IMHO. But if > you're dealing with > money, it's probably a safer bet to stick with Oracle, though > I'm not sure > that's going to be true for much longer. >

2 1

RE: Oracle
by James Sissel 08 Mar '05

08 Mar '05

Oracle is not just the database. The have a whole suite of applications to help you run your business from Accounting to Shipping to Inventory to Manufacturing to Human Resources and more. The assimilation of PeopleSoft (resistance is futile) will add to their suite. With their support for these products companies are relieved of the expense of development. Smaller companies wouldn't have the resources build an Accounting program or to comply with a lot of the government mandated requirements. Tax time would be total Hell. Audits would become a major show stopper. For larger companies they would be overwhelmed with just the day-to-day things that are done and wouldn't have time to do anything else. Remember, a company must do business to make money and if all of their time is just working on their books they aren't making money. The database is just the repository of the data. It's what you do with it that makes the difference.

1 0

Oracle
by Brian Densmore 08 Mar '05

08 Mar '05

I recently acquired an older version of Oracle (v. 8i). I was wondering if it might be possible to load it on a Linux box? Or if I need to break out the NT cd's? I haven't even opened the shrink-wrap yet. I was thinking about using it at home for projects, or possibly on an alternate PC for access by my webserver. Brian Densmore

2 1

RE: logrotate problem
by Brian Densmore 07 Mar '05

07 Mar '05

> -----Original Message----- > From: Frank Wiles > > On Fri, 4 Mar 2005 15:04:18 -0600 > "Brian Densmore" wrote: > > ... > > > > I'm getting a system email with the following text. > > > > /etc/cron.daily/logrotate: > > error running shared postrotate script for > /var/log/apache-ssl/*.log > > run-parts: /etc/cron.daily/logrotate exited with return code 1 > > > > Two things of note. First the log.1 files seems to be the active log > > files. Secondly the current log files have an older date, the same > > date as when I think the logrotate started failing on the apache-ssl > > files. ... > > What is in /etc/logrotate.d/apache or the related logrotate config > file? dunsmuir:/etc/logrotate.d# cat apache-ssl /var/log/apache-ssl/*.log { weekly missingok rotate 52 compress delaycompress notifempty create 640 <uid> <uid2> sharedscripts postrotate /etc/init.d/apache-ssl reload > /dev/null endscript } ******************* Hmmm ... ran "/etc/init.d/apache-ssl reload" manually. Which causes this to happen: dunsmuir:/etc/logrotate.d# /etc/init.d/apache-ssl reload Reloading apache-ssl configurationNo /usr/sbin/apache-ssl found running; none killed. failed hmm ... dunsmuir:/etc/logrotate.d# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 1260 72 ? S 2004 0:33 init [2] root 2 0.0 0.0 0 0 ? SW 2004 0:36 [keventd] root 3 0.0 0.0 0 0 ? SWN 2004 5:06 [ksoftirqd_CPU0] root 4 0.0 0.0 0 0 ? SW 2004 37:15 [kswapd] root 5 0.0 0.0 0 0 ? SW 2004 0:00 [bdflush] ... <uid> 32273 0.0 0.1 3004 72 ? S Feb25 0:00 /usr/lib/apache-ssl/gcache 33 /var/run/gcache <uid> 32274 0.0 2.2 110168 844 ? S Feb25 2:03 /usr/sbin/apache-ssl <uid> 32275 0.0 5.6 110140 2104 ? S Feb25 2:10 /usr/sbin/apache-ssl <uid> 32276 0.0 19.5 110812 7304 ? S Feb25 2:55 /usr/sbin/apache-ssl <uid> 32277 0.0 18.3 110564 6860 ? S Feb25 2:09 /usr/sbin/apache-ssl This also failed, sort of : dunsmuir:/etc/logrotate.d# /etc/init.d/apache-ssl restart Reloading apache-ssl modulesstart-stop-daemon: warning: failed to kill 12457: No such process No process in pidfile `/var/run/apache-ssl.pid' found running; none killed. Reading key for server www.amason.net:443 Launching... /usr/lib/apache-ssl/gcache pid=20301 I killed all processes related to apache-ssl and started it from scratch. What would cause something like that? Thanks, Brian

2 1

Checking System Utilities - cleaner version
by Don Erickson 07 Mar '05

07 Mar '05

I've cleaned up the testutils.pl script and the instructions, and am re-posting this to get a cleaner copy in the archives. - I've been thinking about this rootkit detection and exposure issue, and here are my thoughts: To me, in determining the integrity of any system, the core question is, have the system utilites been compromised? In the equestrian sporting world there is a saying, "Pretty is as Pretty does." From this philosophy, what do the utilites say, and is there a difference between the output of the utilities on the machine and "known clean" utilities? I can't get completely past the feeling that any other test is just window dressing, and while they are all useful tools, it seems to me that any of them could possibly be compromised with a sophisticated enough rootkit. When you are root, _in theory_ you can rewrite md5sums, dates, and even remote hosts used to retrieve live trusted sums. I know of no rootkits that currently do this, but I can imagine how it might be possible. Anyways, with help from a "Building a live CD" article in this month's Linux Journal, here is the procedure that I have come up with to test system utilities on any machine without a reboot: You need a knoppix cd and about 2 gig of space to use the utilities on the knoppix cd. Here's the recipe: Drop the KNOPPIX cd into the tray. Download the cloop-utils package, on debian this is # apt-get install cloop-utils Mount the Knoppix cd: # mount /dev/cdrom /mnt Extract the compressed knoppix filesystem (this will take a while) # extract_compressed_fs /mnt/KNOPPIX/KNOPPIX > /tmp/knoppix-compressed Then mount the extracted filesystem. # mkdir /tmp/knoppix; mount -o loop /tmp/knoppix-compressed /tmp/knoppix Okay, now you're set. Is there a difference in the output of the current system utilities and that of the knoppix cd utilities? Here's a perl script to check: -------8<------------------------------------------ #!/usr/bin/perl # testutils.pl Don Erickson 2005 ######################################################################## # # This script will test the output of commonly trojaned programs. # # The live Knoppix disc must be cloop mounted at /tmp/knoppix/ # ####################################################################### @testthese = ("ps ax", "df", "netstat", "ifconfig", "ls -R", "iptables -L", #"du / -x --exclude=tmp" ); $i=0; $outfile="/tmp/testresults.txt"; $sysout="/tmp/sysout";$knoppixout="/tmp/knoppixout"; open(OUTFILE,">$outfile") || die "Can't open $outfile"; close(OUTFILE,"$outfile"); open(OUTFILE,">>$outfile"); foreach (@testthese) { $testpath = `which $testthese[$i]`;$testpath =~ s/\n//; $testargs = $testthese[$i];$testargs =~ s/^[^ ]+//; $testthis = $testpath.$testargs; print "Testing output of '$testthis'\n"; print OUTFILE "\n########\nDiff of $testthis :: '<' = system '>' = knoppix\n\n"; print "System..."; system("$testthis > $sysout"); print "done. Knoppix..."; system("env LD_LIBRARY_PATH=/tmp/knoppix/lib /tmp/knoppix$testthis > $knoppixout"); print "done.\n"; system("env LD_LIBRARY_PATH=/tmp/knoppix/lib /tmp/knoppix/usr/bin/diff $sysout $knoppixout >> $outfile") == 0; $i++; } print OUTFILE "Tests concluded.\n"; print "Tests concluded.\n"; print "Read the results in $outfile\n"; exit; --------->8----------------------------- Obviously this script can be edited to test the output of any utility that you wish to check, just add the command to the @testthese array. I'm sure that there are lots of lists of "normally rewritten utilities" for most rootkits on the web. The 'du' test is commented out as this one will take a chunk of time to run. The results will show expected differences, but any seriously funny stuff should reach out and grab you by the throat. If anybody sees any flaws in my thinking here, feel free to point them out. At this point I don't see why this wouldn't work, and while trojaned kernel modules are getting more common in rootkits, I can't think of how a trojaned utility could hide from this type of scrutiny. Regards, -Don

4 5

Checking System Utilities
by Don Erickson 06 Mar '05

06 Mar '05

I've been thinking about this rootkit detection and exposure issue, and here are my thoughts: To me, in determining the integrity of any system, the core question is, have the system utilites been compromised? In the equestrian sporting world there is a saying, "Pretty is as Pretty does." From this philosophy, what do the utilites say, and is there a difference between the output of the utilities on the machine and "known clean" utilities? I can't get completely past the feeling that any other test is just window dressing, and while they are all useful tools, it seems to me that any of them could possibly be compromised with a sophisticated enough rootkit. When you are root, _in theory_ you can rewrite md5sums, dates, and even remote hosts used to retrieve live trusted sums. I know of no rootkits that currently do this, but I can imagine how it might be possible. Anyways, with help from a "Building a live CD" article in this month's Linux Journal, here is the procedure that I have come up with to test system utilities on any machine without a reboot: You need about 2 gig of space to use the utilites on a knoppix cd, and a knoppix cd. Here's the recipe: Drop a KNOPPIX cd into the tray. Download the cloop-utils package, on debian this is # apt-get install cloop-utils Mount the Knoppix cd: # mount /dev/cdrom /mnt Extract the compressed knoppix filesystem (this will take a while: go bake a cake or something) # extract_compressed_fs /mnt/KNOPPIX/KNOPPIX > /tmp/knoppix-compressed Then mount the extracted filesystem. # mkdir /tmp/knoppix; mount -o loop /tmp/knoppix-compressed /tmp/knoppix Symlink the libraries to the knoppix directory: Okay, now you're all set. Does the output of the utilites match? # ps ax > /tmp/sysout; env LD_LIBRARY_PATH=/tmp/knoppix/lib \ /tmp/knoppix/bin/ps ax > /tmp/knoppixout; \ diff /tmp/sysout /tmp/knoppixout Obviously these commands must be edited for any utility that you wish to check, I'm sure that there are lots of lists of "normally rewritten utilities" for most rootkits on the web and a script could be written check them all. ps ax will show expected differences, but any seriously funny stuff should reach out and grab you by the throat. If anybody sees any flaws in my thinking here, feel free to point them out. At this point I don't see why this wouldn't work, and I can't imagine how a rootkit could hide from this type of scrutiny. Regards, -Don

1 1

logrotate problem
by Brian Densmore 05 Mar '05

05 Mar '05

Greetings luggites. I've been getting this error for several days now. Not much of a problem, but I would like to know why and how to fix it. I'm getting a system email with the following text. /etc/cron.daily/logrotate: error running shared postrotate script for /var/log/apache-ssl/*.log run-parts: /etc/cron.daily/logrotate exited with return code 1 Two things of note. First the log.1 files seems to be the active log files. Secondly the current log files have an older date, the same date as when I think the logrotate started failing on the apache-ssl files. I have today manually "rotated" the log files. This I did by: creating a new directory for the old gzipped files, gzipping the very large log files, moving them to version *.log.2.gz, moving the "current" log files to *.log.1, and touching *.log files. Not much else to go on. I thought perhaps it might have something to do with the size of the log files, or the number of old log files. One would expect logrotate to handle both cases. Brian Densmore "Three OS's from corporate-kings in their towers of glass, Seven from valley-lords where orchards used to grow, Nine from dotcoms doomed to die, One from the dark lord Gates on his dark throne In the Land of Redmond where the Shadows lie. One OS to rule them all, one OS to find them, One OS to bring them all and in the darkness bind them, In the Land of Redmond where the Shadows lie." john thrum

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

KCLUG