Linux Version of filePro....Redhat vs Debian

On Fri, Apr 06, 2007, Walter Vaughan wrote: >Scott Walker wrote: > >> I have several customers running our fp based application on Red Hat >> Linux (various versions 7, 8, 9, Enterprise 3, Enterprise 4, Fedora 3, >> Fedora 4). They all seem to work fine. >> >> I have a another customer thinking of migrating from SCO to Debian >> Linux. How different should I expect that to be from the Red Hat stuff. >> Does it use the same fp runtime executables? Any comments appreciated. > >Comments? This list? >You are migrating from SCO, so I guess this won't be a workstation. If >someone is going to use it as a desktop, Ubuntu gets my vote these days. >Even the laptop that I won at the filepro Developers conference in 2003 >(wait, I'm typing on that machine right now) is running Xubuntu. Hands down >it passes the "grandmother test". I love it. It actually controls the ACPI >properly. With WindowsXP it would lockup sporadically on wake from suspend, >screen savers, or just lock up. I put the windows drive back in, and it >locked up within 2 hours. I think my uptime is about a month now and is >running within a second from a suspend. I've played a bit with ubuntu, but haven't gotten to the point that I really like it. Some of this is because I'm not accustomed to the debian style package management, and some because I get turned off by the religious attitudes of the GNU/Linux sect. >From the server side, my first love is FreeBSD. But I *have* to recommend >CentOS or Ubuntu as a server. CentOS because it's Red Hat Enterprise Linux >(and I've used for nearly a year on a Tomcat server) and you or whomever is >admining it is experienced with "yum update". If "apt-get" get you going, >then Ubuntu because it can be installed as a character only server based >upon Debian, except with the billions of $USD of engineering that >Cannonical is putting into the project. We have one FreeBSD 4.8 server that's been down once in the last three years when we had a power outage at 3am that I slept through so didn't fire up the generator. Following the FreeBSD mailing lists (which are at least as verbose as the FP list :-), I'm not all that comfortable with the way it's been going as things seem to be changing rapidly and there may be stability problems. I'm not sure that things Novell/SuSE are as bad as they're painted by Groklaw, Stallman, and some of the Samba team. At least one of my friends who's been very involved with Linux for years, and held very high positions in major Linux companies, hypothised that the Microsoft/Novell agreement may have been influenced by the European Union's (EU) anti-trust actions. IMHO, SuSE's Enterprise Linux is the best engineered Linux distribution I've seen, and I haven't had significant problems with numerous SuSE Linux Enterprise 9 and 10 systems here and at customer sites. We don't run any distribution's server software, but use the OpenPKG.org versions which are the same across all systems, FreeBSD, Linux, HP-UX, et al. >I hope those other servers are not visible to the internet. Everything but >the RHEL3/4 and FC3/4's can be owned at will, and the FC3 and FC4 are >EOL'ed. I can't speak to the Red Hat distributions as I have never run any of them other than some superficial testing. What I can say is that the cracked Linux systems I've seen have generally been cracked because of poor administrattion, weak passwords, security holes in PHP, and webmin/usermin attacks. Some steps to reasonable *nix system security are: 1. Only allow secure shell access from outside systems using authorized_keys authentication where the user's keys are protected by proper pass phrases. 2. Don't allow password authentication with secure shell. If you have customers who absolutely insist that they can't figure out how to set up identity authoriztion, and must, for some reason, allow password authentication, then restrict access using tcp_wrappers, restricting allowed systems via /etc/hosts.allow. 3. Set user shells to ``/bin/false'' if possible, or for FilePro users, make their shell go directly to a menu, and exit when they quit so nobody can get a shell. This doesn't restrict e-mail access via IMAP or POP. 4. Use a program to monitor logs, ``swatch'' is good for this, and ``fail2ban'' can automatically block IP addresses using iptables when it detects multiple ssh attempts to log in. 5. Don't use webmin or usermin unless you can restrict access to an internal LAN. They're very handy programs, written in perl which isn't exploited as often as php, but they have provided holes. I've found that usermin is exploited more often than webmin. If you're going to use it, edit the miniserv.acl file to remove potentially dangerous services (chfn in particular can be used to gain root access to unpatched SuSE systems). Bill -- INTERNET: bill at Celestial.COM Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 ``Our Foreign dealings are an Open Book, generally a Check Book.'' Will Rogers