On Sat, 10 Apr 1999, Dave Mielke wrote:
> On Sat, 10 Apr 1999, Myst wrote:
> >This is Linux RedHat 5.2 I'm running and it doesn't
> >matter who packaged the thing - it's RedHat software and RedHat should give
> >me technical support!
>
> That may be what you'd like, but you're being unreasonable. RedHat survives by
> selling support. You are expecting free support, when you haven't even
> supported them. The distributer you used probably got its RedHat image for
> free, as RedHat makes its stuff available for free. Since you paid your money
> to that distributer, it is the company which should be supporting you.
>
> >And, Macmillan Digital Publishing hasn't answered the
> >request for technical support I emailed them over a week ago -
>
> I guess you now know who not to do business with in the future. Next time, why
> not do business with RedHat directly?
Well first of all, I didn't realize that I -wasn't- buying a RedHat product.
When a customer goes into a software store and buys a package that says
"The Complete Redhat Linux 5.2 Operating System Deluxe", one assumes that
they are buying it a _Redhat_ product.. There is nothing on the box that
states otherwise. Secondly, if RedHat wants customer support, they shouldn't
let anyone else package their product and sell it - at least without being
very specific about the distributors packaging being very clear in stating
that the product they are buying is NOT a RedHat Linux product. I would
have been happy to support them with my 40 bucks if they had HAD the
product in the OfficeMax store I bought it from to begin with.
But regardless, RedHat's not giving customers who are using their operating
system technical support just because they didn't buy it specifically from
them is pretty shabby - pretty much the equivalent of HersheysSquirt Inc
telling a handicapped customer they won't help them open their child-proof
squirtbottle because the product was purchased at K-Mart and not directly
from them.
> >so I end up with NO technical support at all? *sigh*
> >
> That's exactly what these mailing lists are for, aren't they?
Mailing lists are fine, but a real voice on the end of the line always
makes one feel so much more confident. =)
> >* I can telnet fine from the hub, but I can't telnet directly from the other
> > machines as I could before, I have to telnet to the hub first, and then I
> > can telnet out from there.
>
> Please let us know what commands you issue in ordder to get your routing set
> up, and to activate IP masquerading. Without information of this sort, it is
> impossible for any of us to adequately help you.
Actually I don't issue any commands to set the routing up - it's just the
way the kernel set it up when I installed it. I have to delete a route:
route del 0.0.0.0 netmask 0.0.0.0 eth0
in order to be able to telnet out from the hub. I don't have a clue what
is creating that route to begin with. I'll use these 2 examples from the
2 main machines' routing tables (the hub being Pandora):
(Original setup still in place - I want to keep this config):
ZELDA:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window Use Iface
192.163.2.0 * 255.255.255.0 U 1436 0 103 eth0
127.0.0.0 * 255.0.0.0 U 1936 0 12 lo
default 192.163.2.254 * UG 1436 0 0 eth0
(192.163.2.254 is Pandora, the hub)
PANDORA:
Kernel IP routing table (before route deletion)
Destination Gateway Genmask Flags Metric Ref Use Iface
198.109.192.42 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.163.2.0 0.0.0.0 255.255.255.0 U 0 0 7 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 3 lo
0.0.0.0 192.163.2.0 0.0.0.0 UG 0 0 29 eth0
0.0.0.0 192.163.2.1 0.0.0.0 UG 1 0 0 eth0
PANDORA:
Kernel IP routing table (after route deletion)
192.163.2.0 0.0.0.0 255.255.255.0 U 0 0 7 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 3 lo
(NOW I can telnet out)
> >* My old PPP script had a +ua option in it. The script will no longer
> > work - it complains there is no such option any more. Is there a new
> > replacement that I can substitute for the +ua option?
>
> Now don't get too picky! Perhaps it's time you took some time to understand
> your old scripts and/or to move ahead into the future instead of expecting
> everyone else to help you remain in the past.
My old script gave me the options of: ppp start|ppp stop|ppp reset, didn't
write my password to /var/log/messages, didn't require that I put a name
and password in a pap-secrets file (which would be very easy to get should
anyone ever manage to hack root), and worked with _both_ of my ISP's. I
have a very simple, stupid one working now that at least dials one of my
ISP's, but will NOT dial the other one no matter what. :( Change is not
always necessarily good unless it's done right. Software that is released
time and time again should always be backwards compatable.
Here's the only thing I could find on that +ua option:
+ua
Agree to authenticate using PAP [Password Authentication Protocol] if
requested by the peer, and use the data in file <p> for the user and
password to send to the peer. The file contains the remote user name,
followed by a newline, followed by the remote password, followed by
a newline. This option is obsolescent.
The line in my ppp script that hangs it is: +ua $AUTHFILE
I can't find any way of working around this other than using the pap-secrets
file. However the pap-secrets file won't work for me because I have to
authenticate to my ISP by first answering the "Host:" prompt as "ppp", and
then the "ame:" prompt as "[EMAIL PROTECTED]" then the password.
Apparently the username must be the same in the pap-secrets file as it is in
the machine's /etc/passwd file, which of course, there is no user with the
name [EMAIL PROTECTED] So I'm really stuck here. Isn't there any
way to replace the +ua option with anything in the new pppd?
> >* I either flagged "News Server" when I configured, or I failed to UN-flag
> > it, but now my hub is "opening a session for user news" every few minutes
> > and I'd like to un-do it, but I can't find any docs that tell me how.
>
> Either shut down the news server vi "chkconfig innd off", or uninstall the
> entire news package via "rpm -e inn". Either way, reboot after the change.
Okie, one problem solved (I hope).. thanks. =) I got this though:
cannot remove /var/spool/news/innfeed - directory not empty
cannot remove /var/spool/news - directory not empty
cannot remove /var/run/news - directory not empty
cannot remove /var/log/news/OLD - directory not empty
cannot remove /var/log/news - directory not empty
cannot remove /var/lock/news - directory not empty
cannot remove /var/lib/news/innd - directory not empty
cannot remove /var/lib/news - directory not empty
cannot remove /usr/lib/news/bin/control - directory not empty
cannot remove /usr/lib/news/bin - directory not empty
cannot remove /usr/lib/news - directory not empty
cannot remove /etc/news - directory not empty
Is it OK to just delete those directories now? Or does anything else
look for them? <Just don't wanna have to go through all this again!> :P
Thanks for your time and help! =)
-Kathi
