- Roundtable - muug.ca

Mac to PC serial
by author 22 Nov '01

22 Nov '01

Thanks Gilbert. Got files sent both ways between the MacSE and PC. The PC ( a 486 with Slackware3.6 ) will only download in Xmodem, but can send in Zmodem. The only real problem left is the PC speaker. Minicom gets it beeping after a successful upload or download, which is fine, except it doesn't turn off. It goes into a terrible howl until I exit minicom and press any key on the command line. So I disconnected the 486 speaker to save my ears and all is well. Next I want to figure out the pin connections and make a cable just for this connection. As it is now, I'm using a Mac modem cable, a Null modem cable, and a gender converter, all for this one task, which seems a waste. Thanks again!

1 0

Null modem serial connection minicom
by author 21 Nov '01

21 Nov '01

I'm trying to set up a nullmodem serial connection between a PC (Linux) and a MacSE (OS6.04). I've got some files I want to pump into the old Mac without having to mess with its floppy drive. Anyway, I've got the computers connected with the correct hardware, that is, a Mac serial modem cable pluged into a a 25 pin null modem cable. Zterm on the Mac is all set, but I'm not sure how to set up minicom for a pure serial connection. Everthing I've read about minicom is for a modem, not a serial connection. So here is the question: How do you set up minicom for a simple null modem serial connection? Any information would be appreciated.

2 1

NTP - It's about time!...
by gedetil＠cs.umanitoba.ca 20 Nov '01

20 Nov '01

(Sorry, I couldn't resist the bad pun.) Just a quick note to say I've updated the write-up of the November MUUG meeting on our web site... http://www.muug.mb.ca/meetings/ ... to include links to the web sites mentioned in the meeting, including the one for NTP. Also, someone had asked whether ntpd under Linux would update the hardware (CMOS) clock or not. It doesn't - it only deals with the system clock (the internal kernel clock that counts time elapsed since a particular epoch). Unfortunately, within Linux, those two clocks are kept independent, and can actually be keeping different time. The solution, if you want to make sure your hardware clock is at least periodically synched up to the system clock, would be to run a cron job to do this via the "hwclock" command. I've attached a simple little script that does the job, and takes things into account like whether the clock is keeping time in UTC (GMT) or local time, and whether the clock is in ARC format (used by certain Alpha-based systems) or not. The script used to run the "rdate" command to update the system clock first, but I've commented that out, since you'd obviously not want to do that if you're running NTP. -- Gilbert E. Detillieux E-mail: <gedetil(a)cs.umanitoba.ca> Dept. of Computer Science Web: http://www.cs.umanitoba.ca/~gedetil/ University of Manitoba Phone: (204)474-8161 Winnipeg, MB, CANADA R3T 2N2 Fax: (204)474-7609

1 0

Re: [RndTbl] how do you install a adaptec ava1505 scsi controller
by gedetil＠cs.umanitoba.ca 20 Nov '01

20 Nov '01

According to S/C Conway: > What is the process to install a scsi controller in RedHat 7.1? I have a > workstation loaded and operational. I tried installing a SCSI controller > (i/o=0x140, Int=10) to host a Sony CDROM burner with no success.The > parameters are jumpered on the board. I tried installing the card from a > complete new linux installation and also tried installing the card after > the OS is up and running. No success either way. The card does not appear > to be detected. RedHat indicates the card is supported using aha152x > driver. I'm not familiar with this card. Is it an ISA bus card, or PCI bus? If it's PCI bus, it should have been auto-detected and configured correctly as long as it's a supported card. However, if it's ISA, it's possible that it won't be auto-detected, and that you'll have to set up the configuration manually. If you're sure the aha152x driver is the right one, you should be able to manually load the driver with "modprobe". If you get that far, then the following setup should work... - Add the following line to /etc/modules.conf: alias scsi_hostadapter aha152x - If you need to explictly set I/O address and/or IRQ values for the driver, then also add a line like this: options aha152x io=0x140 irq=10 (Check the driver documentation, though, as I'm not sure if these are the right options for that driver.) - Build (or rebuild) your initrd file for the kernel: mkinitrd /boot/initrd-2.4.9-12.img 2.4.9-12 (Adjust the numbers above to match those for your installed kernel.) - If not already done, add an initrd statement in /etc/lilo.conf: initrd=/boot/initrd-2.4.9-12.img (This should be after the "image=" line for the kernel to be booted.) - Run "lilo", and reboot. The reason for the slightly convoluted setup is that Red Hat configures its kernels to load the SCSI driver as a module, but that module has to be made available in an "initrd" file (initial ramdisk image), in case the system is installed on a SCSI disk drive, in which case the file system wouldn't be accessible until the driver is loaded. (Sort of a catch 22 bootstrapping problem.) Because of the way Red Hat sets this up, you still need to do it this way, even if you're not using the SCSI driver to access your system disk. > The card works. It now hosts a SCSI scanner and CDROM burner in a windows > box. If I can successfully install the card I hope to eliminate that > windows box. > > I was hoping someone had some experience with this type of installation > and might offer a stepped process to success. As I said, I'm not familiar with your card, but the above setup has worked for me for a number of cards, both ISA and PCI bus based. (Although I've never had to override I/O or IRQ settings with an options statement.) -- Gilbert E. Detillieux E-mail: <gedetil(a)cs.umanitoba.ca> Dept. of Computer Science Web: http://www.cs.umanitoba.ca/~gedetil/ University of Manitoba Phone: (204)474-8161 Winnipeg, MB, CANADA R3T 2N2 Fax: (204)474-7609

1 0

Screen Resolutions in RH 7.1
by Geek 19 Nov '01

19 Nov '01

Ok, this will be simultaneously posted in three different lists,m the TuxTalk list, the Talkabout mail list, and the MUUG Round Table list. Hopefully between these three resources I will find an adequate solution. I finally got a nicely running install of Red Hat 7.1 today, after much hassle and great help from those I know. The problem now is that the screen resolution is too small, and the GUI(KDE) looks quite grainy. After the install it was at 640x480, and a little run through of Xconfigurator brought it up to 800x600, but it is still not to what I am either used to or like. I want either 1024x768 or 1152x800. This is the last issue that needs to be resolved before I try to migrate to Linux as much as possible, with only absolutely necessary stuff being done in Windows. I tried various different sites, like Google and the Linux documentation project, but I have been unable to get a satisfactory resolution. Thanks in advance for your help, and I will post the best and most effective solution on all of these lists as soon as one is found. Thanks a lot in advance. New Blog online http://blog.geeksworld.net/ ****Finally back online http://www.geeksworld.net *****

2 1

LinuxNews.com
by Ian T. 16 Nov '01

16 Nov '01

In the article below (see the link), I'm unclear as to what he is referring to as Red Hat's "proprietary directory technology". If anyone has read the article or cares to follow up and comment, I'd appreciate it. I'd like to more information regarding these issues. If people have links to similar content please post it or contact me directly. ========================== Microsoft `Gets It': Does the Linux Community? - LinuxNews.com Features Posted by Dr. G.W. Wettstein on Thursday October 05 2000 @ 01:49PM MDT In light of all this, you can imagine our surprise and ultimate dismay when we see a major Open-Source player such as Red Hat choose to embrace proprietary directory technology. It's either a matter of not understanding the issue, not appreciating the issue, or having non-technology issues drive the corporate decision making process. ==========================-- Cheers! Ian. N 49 12' 30" W 96 53' 45"

1 0

how do you install a adaptec ava1505 scsi controller
by S/C Conway 16 Nov '01

16 Nov '01

What is the process to install a scsi controller in RedHat 7.1? I have a workstation loaded and operational. I tried installing a SCSI controller (i/o=0x140, Int=10) to host a Sony CDROM burner with no success.The parameters are jumpered on the board. I tried installing the card from a complete new linux installation and also tried installing the card after the OS is up and running. No success either way. The card does not appear to be detected. RedHat indicates the card is supported using aha152x driver. The card works. It now hosts a SCSI scanner and CDROM burner in a windows box. If I can successfully install the card I hope to eliminate that windows box. I was hoping someone had some experience with this type of installation and might offer a stepped process to success. Sean

1 0

MUUG Meeting, November 13, 7:30PM -- Mini-HOWTO's on NTP and XINETD
by gedetil＠cs.umanitoba.ca 06 Nov '01

06 Nov '01

[Posted to man.unix.general and other news groups] ------ Forwarded Article <9s9813$b57$1(a)canopus.cc.umanitoba.ca> ------ From gedetil(a)cs.umanitoba.ca (Gilbert E. Detillieux) The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, November 13. The meeting topic for this month is as follows: Mini-HOWTO's on NTP and XINETD This month, MUUG members Kevin McGregor and Gilbert Detillieux will each be covering a short topic, in a mini-HOWTO format. Kevin McGregor will be talking about NTP, the network time protocol, and the UNIX daemon which provides support for this protocol. Gilbert Detillieux will be talking about XINETD, a powerful replacement for the UNIX INETD daemon, used for launching numerous TCP and UDP based network services. The group holds its general meetings at 7:30 PM on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. ********************************************************************** New Location: Once again this month, and from now on, the meeting will be at the IBM offices, at 400 Ellice Ave. (between Edmonton and Kennedy). When you arrive, you will have to sign in at the reception desk, and then wait for someone to take you (in groups) to the meeting room. Limited parking is available for free on the street, or in a lot across Ellice from IBM, for $1.00 for the evening. Indoor parking is also available nearby, at Portage Place, for $2.00 for the evening. ********************************************************************** For more information about MUUG, and its monthly meetings, check out their Web server: http://www.muug.mb.ca/ Also note that MUUG maintains two mailing lists, called "muug-announce" and "roundtable". If you're not already on these lists, I encourage you to subscribe now: http://www.muug.mb.ca/mailman/listinfo/ The "muug-announce" list is used for monthly meeting announcements (such as this one) as well as other important announcements of interest to MUUG members. The "rountable" list is meant to be a forum for follow-ups to topics discussed at the meetings, or for round-table-style discussion on other topics that come up between meetings. Of course, for this to be effective, we need to reach a certain critical mass. So, please subscribe, and stay involved! -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ P.O. Box 130, St-Boniface Phone: (204)474-8161 Winnipeg, MB, CANADA R2H 3B4 Fax: (204)474-7609 ------ End of Forwarded Article

1 0

RE: [RndTbl] TD network failure
by Shewfelt, Doug 30 Oct '01

30 Oct '01

Gilber Detillieux wrote: > According to author: > > Does anyone have any specifics as to why the > > Toronto Dominion Bank had that major failure > > this Saturday, October 27 ? All I hear in the > > media is that it was some kind of > > 'hardware' failure. Nothing specific said. > > I'm in the same boat. I listened to various news reports on > Saturday night, but they just referred vaguely to a "computer > glitch" or a "computer bug", without getting into any details. There's a brief article on it in The Globe and Mail today (http:.//www.globeandmail.com). The full URL that I got when I found the article is the elegant and easily remembered http://rtnews.globetechnology.com/servlet/RTGAMArticleHTMLTemplate/C/2001103 0/wxtdbank?tf=tgam/realtime/fullstory_Tech.html&cf=globetechnology/tech-conf ig-neutral&slug=wxtdbank&date=20011030&archive=RTGAM&site=Technology. It doesn't go into a lot of detail. (I think that banks are traditionally quiet about data processing problems.) Here are a couple of paragraphs that give a little information: The crash was caused by the failure of a single "motherboard" in one of the bank's central computers at about 11 a.m. Saturday. This "gradually started to shut down the system" to "protect the integrity" of the data already there, Mr. Livingston said. "It was a purely random event," he said, adding that hardware failures are rare. "This has never happened before, and it will likely never happen again." Although the bank's credit card system "stayed on the air pretty much all day," and its debit card system also continued to function "intermittently," Mr. Livingston said, everything else went down. This included its telephone and Internet banking operations, in-branch computer systems and approximately 2,000 automated banking machines. Customers also were unable to gain access to their money through other banks' ABMs. [...] As TD sought to identify and fix the problem, "a few million transactions" were rejected by the bank's systems, which, on a busy Saturday, process up to 500 transactions a second, he said. > > I'd really like to know what happened to > > crash their whole system. I thought the banks > > had 'bullet-proof' networks what with all those > > billions of dollars they have to spend. > > [...] I would > suspect it was not a network problem, per se, but rather a failure of their > account database, for it to affect all modes of account access like that. Gilbert's theory sounds reasonable, especially since the credit card system was working for most of the time. I assume that the credit card system has an independent account database. - Doug

1 0

TD network failure
by author 29 Oct '01

29 Oct '01

Does anyone have any specifics as to why the Toronto Dominion Bank had that major failure this Saturday, October 27 ? All I hear in the media is that it was some kind of 'hardware' failure. Nothing specific said. I'd really like to know what happened to crash their whole system. I thought the banks had 'bullet-proof' networks what with all those billions of dollars they have to spend.

3 2