Date: Thu, 15 Feb 1996 08:34:05 -0800 From: David Muir Sharnoff <muir@idiom.com> To: Nate Williams <nate@sri.MT.net> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Re: An ISP's Wishlist... Message-ID: <199602151634.IAA03261@idiom.com>
next in thread | raw e-mail | index | archive | help
* > Idle time for kernel PPP sessions or at least an idle timeout. * * I'm interested in this. I built something using ip-up and ip-down. They save the mapping of interface -> tty in /var/if and I've got a cron job that runs netstat -in every six minutes and checks for differences from the last run. I didn't send in my work because I don't think this is the right way to do it. It solved my problem though. I think there may be enough interest for me to post it anyway. * > Ability to add a route (not a default route) with pppd. * * Isn't this already doable w/out hacks using /etc/ppp/ip-up and * /etc/ppp/ip-down? That's where I do it, but it was very annoying because at the time I was invoking pppd, I knew what routes to add. * > A better (doens't have to use /etc/passwd) POP server in ports. * > (There seems to be one in the mh distribution) * * Huh? What's wrong with using /etc/passwd? Also, the POP server in * ports is the 'de-facto' standard that most folks end up using. The default pop server doesn't map uppercase to lowercase and my users are messing that one up frequently. I'm going to change the source shortly. As for /etc/passwd, what I would really like to be able to do with pop is provide mailboxes in domains other than my own. info@idiom.com and info@customer-domain. * > automatic reboot and report of diagnostics when the system * > hangs in disk wait. * * I think the 'watchdog' board talked about at length would be a solution. Sorry, I missed the discussion. It's funny, I wrote the Wishlist over a period of several weeks, but I still managed to leave off some important things. Perhaps the most important thing for me is the ability to manage a system remotely. In particular, I want to be able to recover from a corrupted root filesystem. I don't know how well the serial console stuff works. Can you select your boot device from a serial console? If so, it's easy enough to have an extra disk (sd0) that isn't used for anything except to redirect boots to sd1. If something goes wrong with sd1, then sd0 can be used to fix sd1. Or at least that was my tentative thought. I was figuring: arrange the computers in a ring of consoles. Give each one an cheap/slow disk 0 that isn't normally used. Boot for real off of disk 1 which is removable (for easy upgrades). Use X10 units for when things go really bad. It would be nice to have some way of remotely hitting the reset button, but cycling the power will do. While what I'm describing is kind of a high-end remote management solution, there is need for easier things: lots of ISPs are selling co-location services. The people buying these services need to be able to manage their computers. * > During major disk activity on disks 1 & 2, (tar | tar), small * > accesses to disk 3 seem to pause for a long time. Since the * > tar|tar is a news filesystem, most of the time spent is doing * > synchronous writes to disk 2. Such writes should not cause * > delays to reading disk 3. Environment: 2.1-STABLE, ncr53c810, * > disks are 7200rpm'ers from Seagate & Micropolis. * * Do you have only one controller? If your SCSI bus is saturated, there * is nothing FreeBSD can do to put more data on the wire. I have only one controller, but this was a news filesystem that I was moving. Small files. I was getting less than 2MB/second through the controller. Reading large files I can get over 8MB/second. * > Reliable and secure NIS or an equivelent. * * What's wrong with the NIS implementation already distributed? (Having * secure and NIS in the same sentence is comical. It's almost as bad as * having secure and NFS in the same sentence. :) I don't trust that it is secure. A secure solution to the distributed user authentication database problem is needed. * > Pkg_manage enhancements to show what has been installed. * * Umm, what's wrong with 'pkg_info -aI'? Okay, about pkg_manage. First, pkg_manage is a great improvement over pkg_add, but it's still got some problems: 1. It doesn't detect easy failures ahead of time. If one package depends on another, it should detect that itself rather than letting pkg_add fail. Actually, it should probably ask if the other package should be installed. 2. It should run in more of a batch mode. Installing 90% of the packages takes a lot of time. 3. When selecting which packages to install, it needs to let you know which of the packages you are currently looking at are already installed. My pea-brain can't remember them all. 4. Some of the packages can't be installed by pkg_manage because they ask for input in their install scripts. (Some of the tex stuff.) -Dave
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602151634.IAA03261>