Re: lilo on /dev/hdb to work as /dev/hda
> I was able to copy hda to hdb (fdisk, newfs, rsync, lilo) and then use the if [ $(uname) = "Linux" ] ; then sed 's/newfs/mkfs/' ; fi
Re: lilo on /dev/hdb to work as /dev/hda
On Tue, 6 Aug 2002, Kevin J Menard wrote: > This is a shot in the dark, but could you use the bios option to install > lilo onto that drive. Then use a boot disk to boot off of it. Once > it's up, you could then change the bios option back to 0x80, and rerun > lilo, and should be all set. This is a follow-up on my problem. Anyways, using the bios option did work -- and I didn't need a boot floppy or have to rerun lilo again! I was able to copy hda to hdb (fdisk, newfs, rsync, lilo) and then use the disk originally at hdb as hda without any changes. The "boot=" was /dev/hda, but I used "-b /dev/hdb" to override that. And then in the lilo config I did: disk=/dev/hdb bios=0x80 And it wrote the boot loader to hdb so it thought that it was really hda. Jeremy C. Reed http://www.bsdnewsletter.com/ -- BSD news and resources http://www.isp-faq.com/-- find answers to your questions
Re: failure notice (about relays.osirusoft.com)
> > > > I have communicated with Joe Jared on this (not using real > > identification), and while I won't divulge the private communications > > on a > > public list, the general jist is "i don't get legit emails from Asia, > > nor > > do people that use my list. So I could block all of Asia and no one > > would > > care". Those of you that use joe jared's list should be aware of his > > opinions. > > Not going to divulge private commnications, then you go on to do that, > only better yet, you get to paraphrase as you wish. Assuming you even > did have some "communication". I made a remark... i did not divuldge private communications. Take it whatever way you wish. > Why did you feel it necessary to do that without "real identification"? > Why not put your name on it? > > The better your question, the better your answer. Why should I reveal my real name? Who's to say "Joe Jared" is HIS real name? Anyway, I wanted to get some truths about what was going on... even SPEWS, one of the most militant groups, and all the other "RBLs for spam sources" are not listing iAdvantage now. Why would osirusoft pick it up just recently? Anyway... looking at your arguments concerning Spam in the past: http://groups.google.com/groups?q=cfm%40maine.com+spam&hl=en&lr=&ie=UTF-8&; oe=UTF-8&safe=off&selm=20020502134542.GB23194%40maine.com&rnum=1 AND I QUOTE: -- Collateral damage is, however, the only leverage one has get some of these spam friendly ISPs and lazy admins to enforce reasonable use. -- It was once said that it is better to let off 10 criminals than to put 1 innocent man in jail. You, on the other hand, suggest it is better to put 10 innocent men in jail for 1 criminal. Interesting thought. Perhaps none of your users need to communicate with Asia, including China, Hong Kong, Korea, etc. I don't think you have many/any international businesses using your services if the above statment by you is true. It would be funny if one of the branches of a company in Asia cannot even send email to their other branches because of your "strictest possible RBL".
Re: failure notice (about relays.osirusoft.com)
> you seem to have a chip on YOUR shoulder about the osirusoft RBLs. this > is not the first time you have bitched about them in public. Yes... yes I do. I will bitch about things that I see are bad, and try and do things about it (like offer better alternatives). Perhaps you are one to sit on your ass and do nothing. > amusingly, however, you completely discredit your line of argument by > suggesting that bl.spamcop.net is a viable substitute. bl.spamcop.net > isn't even a good RBL let alone any kind of a substitute for osirusoft, > their moronic automation policies (and inevitably inadequate automation > software) result in an enormous number of false positives. to put it > bluntly, anyone using bl.spamcop.net is either running only a tiny > personal mail server or is a complete barking moron. or both. YOU have a chip on YOUR shoulder about the spamcop RBL. this is not the first time you have bitched about them in public. > > your sole complaint against osirusoft is that they list numerous open > relays and spam-sources in Asia which (potentially?) affects you > personally. tough luck. find yourself an ISP which a) has a clue about > running & securing mail servers and b) doesn't allow open relays or > spammers on their network. And what if someone does business in Asia? Oh... your braindead solution of "find another ISP" doesn't cut it for business. Basically you'd be telling people to "move out of Asia" instead? Or maybe you don't have Asian friends that live in Asia. How narrow minded.
Re: failure notice (about relays.osirusoft.com)
> > > SO... if you plan on receiving email from me or Asia, I suggest you use > > RBLs with clear listing and removal policies and methods (eg. the RBLs I > > listed above, and others), > > This is a good policy. Using DNSBL's that don't have some > resolution method for a black listing is risky. However, osirusoft > does have a resolution policy, contrary to your complaint. No they don't... > Simply fix the problem, then ask for a retest. If you retest OK, > then you get taken off the BL. Not possible. Joe has not listed iAdvantage as an open relay, nor anything that you can get off. Hence there is no resolution method... you can visit the militany NANAE newsgroup for resolution, but if you take a look at the messages there ugh... swearing at each other, threats, etc. Take a look for yourself. > Mind you, lists like xbl.selwerd.cx have neither a resolution policy, > NOR a nomination policy. An ip address can end up being black > listed simply because some OTHER ip address initiated some spam. > > Now there is a list to REALLY complain about! Well, I don't think many people are really go and use xbl.selwerd.cx. There are plenty of super militany groups like selwerd like blars.org (i think?) and others. > > and not relays.osirusoft.com (OR if you must > > use osirusoft, then use the pick and choose the individual RBLs under > > relays.orisusoft.com, > > What are you talking about? There isn't, as far as I know, a "list of > RBL's under relays.osirusoft.com". If you are refering to the ability > to query a number of DNSBL's through: > > http://relays.osirusoft.com/cgi-bin/rbcheck.cgi Sure they are. relays.osirusoft.com is a combination of other RBLS like spews, and also Joe Jared's own personal list. It is Joe Jared's own personal list that is the problem... NOT Spews, NOT the other RBLs. > then please realize that the list of DNSBL's that is generated by a > query through this tool are NOT "under" osirusoft.com in any way, > shape or form. Yes... this one is. > > otherwise you'll be using a list that combines many > > other RBLs together, > > No, osirusoft does NOT combine a great many RBL's together, though > there does appear to be some cross fertilization between the various > lists. > I beg you to differ. Alternatively, go there, and enter, just for example, mailserv.iadvantage.net. Try and find another list that has mailserv.iadvantage.net and see for yourself. > > including militant ones and other shoddy ones).
Re: failure notice (about relays.osirusoft.com)
what would be the feature syntax in sendmail.mc for using osirusoft please? im in NZ and sick to death of being spammed from asia :] regards Thing Craig Sanders wrote: > you seem to have a chip on YOUR shoulder about the osirusoft RBLs. this > is not the first time you have bitched about them in public. > > amusingly, however, you completely discredit your line of argument by > suggesting that bl.spamcop.net is a viable substitute. bl.spamcop.net > isn't even a good RBL let alone any kind of a substitute for osirusoft, > their moronic automation policies (and inevitably inadequate automation > software) result in an enormous number of false positives. to put it > bluntly, anyone using bl.spamcop.net is either running only a tiny > personal mail server or is a complete barking moron. or both. > > your sole complaint against osirusoft is that they list numerous open > relays and spam-sources in Asia which (potentially?) affects you > personally. tough luck. find yourself an ISP which a) has a clue about > running & securing mail servers and b) doesn't allow open relays or > spammers on their network. > > craig > > -- > craig sanders <[EMAIL PROTECTED]> > > Fabricati Diem, PVNC. > -- motto of the Ankh-Morpork City Watch > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failure notice (about relays.osirusoft.com)
On Sun, Aug 18, 2002 at 12:27:08PM +1000, Jason Lim wrote: > Dear Russel (and anyone else who is using relays.osirusoft.com), > > Because you are using the combined RBL relays.osirusoft.com, and since Joe > Jared (single operator of relays.osirusoft) has a documented chip on his > shoulder against Asia and iAdvantage (upstream, one of the largest > bandwidth carriers in HK), you'll be missing email from a lot of Asia. There are some DNSBL that block nearly all of Asia. That is because: 1) So very much spam either originates or is relayed through Asian ISP's. 2) Not one Asian ISP has ever responded to any of the spam complaints. Nor, evidently, do they respond to anybody else's spam complaints, either. > Might I suggest 3 effective alternatives (there are many others, but these > ones I've tested and are good): > > relays.visi.com > relays.ordb.org > bl.spamcop.net I use the last two, as well as osirusoft. And my spam input has dropped dramatically since configuring my server to query three DNSBL's. However, in the spirit of keeping my communications as open as possible, I'll switch to visi from osirusoft for a week. If my spam intake doesn't noticably go up, fine. If not, back to osirusoft. > SO... if you plan on receiving email from me or Asia, I suggest you use > RBLs with clear listing and removal policies and methods (eg. the RBLs I > listed above, and others), This is a good policy. Using DNSBL's that don't have some resolution method for a black listing is risky. However, osirusoft does have a resolution policy, contrary to your complaint. Simply fix the problem, then ask for a retest. If you retest OK, then you get taken off the BL. Mind you, lists like xbl.selwerd.cx have neither a resolution policy, NOR a nomination policy. An ip address can end up being black listed simply because some OTHER ip address initiated some spam. Now there is a list to REALLY complain about! > and not relays.osirusoft.com (OR if you must > use osirusoft, then use the pick and choose the individual RBLs under > relays.orisusoft.com, What are you talking about? There isn't, as far as I know, a "list of RBL's under relays.osirusoft.com". If you are refering to the ability to query a number of DNSBL's through: http://relays.osirusoft.com/cgi-bin/rbcheck.cgi then please realize that the list of DNSBL's that is generated by a query through this tool are NOT "under" osirusoft.com in any way, shape or form. This page is simply a tool, provided as a courtesy, that allows the user to test a single IP address against a great many open DNSBL's. > otherwise you'll be using a list that combines many > other RBLs together, No, osirusoft does NOT combine a great many RBL's together, though there does appear to be some cross fertilization between the various lists. > including militant ones and other shoddy ones). http://relays.osirusoft.com/cgi-bin/rbcheck.cgi is not a list of all of the sources that feed into osirusoft. If it were, then I could not use osirusoft, because one of the BL's queried by this tool lists MY address! [ And, no, I've never spammed, nor is my MTA an open relay . . . the guy who runs xbl.selwerd.cx simply lists every IP address owned by the company if *ANY* IP address owned by that company has ever spammed . . . and I buy my net connection from AT&T, one of the biggest cable modem connection providers in the US of A. ] John S.
Re: failure notice (about relays.osirusoft.com)
you seem to have a chip on YOUR shoulder about the osirusoft RBLs. this is not the first time you have bitched about them in public. amusingly, however, you completely discredit your line of argument by suggesting that bl.spamcop.net is a viable substitute. bl.spamcop.net isn't even a good RBL let alone any kind of a substitute for osirusoft, their moronic automation policies (and inevitably inadequate automation software) result in an enormous number of false positives. to put it bluntly, anyone using bl.spamcop.net is either running only a tiny personal mail server or is a complete barking moron. or both. your sole complaint against osirusoft is that they list numerous open relays and spam-sources in Asia which (potentially?) affects you personally. tough luck. find yourself an ISP which a) has a clue about running & securing mail servers and b) doesn't allow open relays or spammers on their network. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: failure notice (about relays.osirusoft.com)
On Sun, Aug 18, 2002 at 12:27:08PM +1000, Jason Lim wrote: > Dear Russel (and anyone else who is using relays.osirusoft.com), > Jared (single operator of relays.osirusoft) has a documented chip on > his > shoulder against Asia and iAdvantage (upstream, one of the largest ... > > I have communicated with Joe Jared on this (not using real > identification), and while I won't divulge the private communications > on a > public list, the general jist is "i don't get legit emails from Asia, > nor > do people that use my list. So I could block all of Asia and no one > would > care". Those of you that use joe jared's list should be aware of his > opinions. Not going to divulge private commnications, then you go on to do that, only better yet, you get to paraphrase as you wish. Assuming you even did have some "communication". Why did you feel it necessary to do that without "real identification"? Why not put your name on it? Maybe he just has a good bullshit radar. And yes, you can quote me. :-) The better your question, the better your answer. -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Content/site management, online commerce, internet integration, Debian linux
Re: failure notice (about relays.osirusoft.com)
Dear Russel (and anyone else who is using relays.osirusoft.com), Because you are using the combined RBL relays.osirusoft.com, and since Joe Jared (single operator of relays.osirusoft) has a documented chip on his shoulder against Asia and iAdvantage (upstream, one of the largest bandwidth carriers in HK), you'll be missing email from a lot of Asia. Might I suggest 3 effective alternatives (there are many others, but these ones I've tested and are good): relays.ordb.org relays.visi.com bl.spamcop.net All of these block spam effectively, and yet all of the above ones clearly list their "listing policies" and "removal policies" on their respective websites, unlike osirusoft that just says "visit nanae" as a solution. Funny thing is... if you do click on the link Joe Jared setup pointing to Google, you'll notice that the number of complaints pales in comparison to those against Rackspace and other large USA hosting and ISPs. The block he has setup blocks about 40-50% of active IP space in HK overall. He wouldn't dare block Rackspace or all that because they are in the USA and are large, and I bet people using his list would drop him like flies if he were to do that (which he should... rackspace is a proven spamhaven, but won't). I have communicated with Joe Jared on this (not using real identification), and while I won't divulge the private communications on a public list, the general jist is "i don't get legit emails from Asia, nor do people that use my list. So I could block all of Asia and no one would care". Those of you that use joe jared's list should be aware of his opinions. SO... if you plan on receiving email from me or Asia, I suggest you use RBLs with clear listing and removal policies and methods (eg. the RBLs I listed above, and others), and not relays.osirusoft.com (OR if you must use osirusoft, then use the pick and choose the individual RBLs under relays.orisusoft.com, otherwise you'll be using a list that combines many other RBLs together, including militant ones and other shoddy ones). Sincerely, Jason - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, August 18, 2002 11:30 AM Subject: failure notice > Hi. This is the qmail-send program at beta.zentek.net. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > <[EMAIL PROTECTED]>: > 203.36.46.209 does not like recipient. > Remote host said: 554 Service unavailable; [203.194.146.7] blocked using relays.osirusoft.com, reason: IADVANTAGE http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&scoring=d&q=IADVAN TAGE+ Visit nanae for removal > Giving up on 203.36.46.209. > > --- Below this line is a copy of the message. > > Return-Path: <[EMAIL PROTECTED]> > Received: (qmail 24127 invoked from network); 18 Aug 2002 01:29:56 - > Received: from unknown (HELO zentekgateway) (150.101.192.86) > by 203.194.146.32 with SMTP; 18 Aug 2002 01:29:56 - > Message-ID: <[EMAIL PROTECTED]> > Reply-To: "Jason Lim" <[EMAIL PROTECTED]> > From: "Jason Lim" <[EMAIL PROTECTED]> > To: "Russell Coker" <[EMAIL PROTECTED]>, > "Debian ISP" > References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > Date: Sun, 18 Aug 2002 11:41:59 +1000 > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 6.00.2600. > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600. >
Re: mail queue's, ext3 data=journal and sync-mount
> Rumour has it that data=journal can actually improve performance in some > situations. If a program is writing lots of small files synchronously (quite > common for a mail server that has one tiny control file for every message, > and the average message file isn't too big) then journalling the data allows > for synchronous writes to a small (8M to 32M) region on disk (which is really > fast) and it'll then be written to it's final destination with the write-back > caching enabled which allows writes to be ordered for good performance. Not rumour... I confirm I have seen the benchmarks for this somewhere. It was in a table format... it compared EXT3 with the various options, REISERFS which various options... too bad I can't remember the webpage, aye? But i am sure it is there somewhere, so I'm sure if you search long enough it'll pop up in google.com or alltheweb.com > Without the data=journal option ReiserFS is rumoured to beat Ext3, with > data=journal ext3 should win. > I would be interested in seeing benchmark data. Also one thing I have been > thinking of doing is benchmarking Qmail vs Postfix... ;) Can I see a mail war brewing? ;-)
Re: mail queue's, ext3 data=journal and sync-mount
I decided that this message is better for Debian-ISP, so I replied to the list and BCC'd you. I hope you don't object. On Sun, 18 Aug 2002 01:20, you wrote: > I'm having some trouble finding info on this stuff and found a > knowledgeable-sounding post of yours on debian-isp. Please ignore if > this is inappropriate. > > I'm going to setup a debian woody system for qmail (and others) and was > hoping to secure the qmail queue a bit. For some reason, sync mounted > ext2 and 3 is abysmally slow. How does FFS do it? anyway, do you know > if ext3 mounted data=journal (or any other way) is sufficient? I have not done any serious tests on such things. If you want to do such tests then I recommend my Postal benchmark program (it's in Debian). But don't try the IMAP option - I haven't finished coding it. Rumour has it that data=journal can actually improve performance in some situations. If a program is writing lots of small files synchronously (quite common for a mail server that has one tiny control file for every message, and the average message file isn't too big) then journalling the data allows for synchronous writes to a small (8M to 32M) region on disk (which is really fast) and it'll then be written to it's final destination with the write-back caching enabled which allows writes to be ordered for good performance. I haven't tested this but it all sounds logical. Without the data=journal option ReiserFS is rumoured to beat Ext3, with data=journal ext3 should win. I don't know much about FFS. I would be interested in seeing benchmark data. Also one thing I have been thinking of doing is benchmarking Qmail vs Postfix... ;) Russell Coker
RE: Binding Multiple IP's to a single NIC
Hello All, Seems that Ip Aliasing is not installed by default with Woody. I've recompiled the kernel and everything works as expected now. Thanks, Lem -Original Message- From: Jason Lim [mailto:[EMAIL PROTECTED] Sent: Friday, August 16, 2002 9:06 PM To: debian-isp@lists.debian.org Cc: debian-isp@lists.debian.org Subject: Re: Binding Multiple IP's to a single NIC I thought the stock Debian kernel came with IP Alias support built in? - Original Message - From: "James Morgan" <[EMAIL PROTECTED]> To: "Lem Bryant" <[EMAIL PROTECTED]> Cc: Sent: Saturday, August 17, 2002 6:02 AM Subject: Re: Binding Multiple IP's to a single NIC > Was your kernel compiled with IP Alias support? (CONFIG_IP_ALIAS) > > At 11:40 2002-08-16 -0500, Lem Bryant wrote: > >Would someone mind pointing a brain-dead user in the right direction? > > > >I've made the eth0:1 entry in my interfaces file, but I get the following > >errors. > > > >ifup eth0:1 > >SIOCSIFADDR: No such device > >SIOCSIFFLAGS: No such device > >SIOCSIFNETMASK: No such device > >SIOCSIFBRDADDR: No such device > >SIOCSIFFLAGS: No such device > >SIOCSIFFLAGS: No such device > >Thanks, > > > >Lem > > > > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SpamAssassin Web Configuration
On Fri, Aug 16, 2002 at 09:11:44AM -0400, Gene Grimm wrote: > Can anyone tell me if there is a canned CGI script to allow clients to > modify their personal settings for SpamAssassin via a web interface? When > looking for this on search engines, I see several providers having something > of this nature but I cannot find any reference to a canned script for this > purpose. > I can't tell you, but I have been keeping this thread around hoping somebody had a suggestion. I expect to be interested in this very soon (at the moment I'm still trying to figure out Procmail & will tackle SpamAssassin after that), If you do learn of something, I would be interested in a follow-up
Re: 50MB mbox size limit with postfix/procmail
Thank you :) That did the trick. Øystein On Sat, Aug 17, 2002 at 03:53:48PM +0200, Andrius Kasparavicius wrote: > mailbox_size_limit = > > On Sat, 17 Aug 2002, Oystein Nerhus wrote: > > > I'm using postfix with procmail for local delivery. Latest versions > > from woody: > > > > ii postfix 1.1.11-0.woody2 > > ii procmail 3.22-4 > > > > When any mbox reaches 50MB, procmail and/or postfix will refuse to > > deliver it to that mbox, and the mail is instead delivered to the next > > matching procmail rule (usually the catch-all rule at the end of my > > .procmailrc file)
Re: 50MB mbox size limit with postfix/procmail
mailbox_size_limit = On Sat, 17 Aug 2002, Oystein Nerhus wrote: > I'm using postfix with procmail for local delivery. Latest versions > from woody: > > ii postfix 1.1.11-0.woody2 > ii procmail 3.22-4 > > When any mbox reaches 50MB, procmail and/or postfix will refuse to > deliver it to that mbox, and the mail is instead delivered to the next > matching procmail rule (usually the catch-all rule at the end of my > .procmailrc file) > > I have tried really hard to find this limit, even by grepping the > sources for both postfix and procmail. I tried setting > "virtual_mailbox_limit = 0" in the postfix main.cf, but no luck. And > yes, I know that the limit most probably lies in procmail(logically that > is) However, I cannot find any such setting in the procmail docs. > > What did I overlook? > > Thanx, > > Øystein > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
50MB mbox size limit with postfix/procmail
I'm using postfix with procmail for local delivery. Latest versions from woody: ii postfix 1.1.11-0.woody2 ii procmail 3.22-4 When any mbox reaches 50MB, procmail and/or postfix will refuse to deliver it to that mbox, and the mail is instead delivered to the next matching procmail rule (usually the catch-all rule at the end of my .procmailrc file) I have tried really hard to find this limit, even by grepping the sources for both postfix and procmail. I tried setting "virtual_mailbox_limit = 0" in the postfix main.cf, but no luck. And yes, I know that the limit most probably lies in procmail(logically that is) However, I cannot find any such setting in the procmail docs. What did I overlook? Thanx, Øystein
RE: Forward email
The forwarding of email is going to be the easiest thing to do, I'd suggest using sendmail, all you need to do is get a local DNS zone working correctly for the domain(s) your trying to relay. How ever, I've been trying to find a smtp virus scanner, and unfortunatly I havent been able to find anything that scans mail on in the fly, the majority of antivirus packages Ive tried for debian will only just scan the user's mailbox, which obviously is no good as there are no user mailbox's on the linux relay. Anyone attempted this before? -Daniel Hooper -Original Message- From: Elcio Mello Sent: Sat 17/08/2002 9:11 AM To: debian-isp@lists.debian.org Cc: Subject: Forward email Hello people, I work at a company, and I have had a lof of problem with virus. Well We have the folowing: | Windows NT | | SMTP - Mailboxs| <--> INTERNET | runing Critical Path | I'm not runing a ant-virus on Windows NT, because it use a lot of cpu. What I want? I would like the folowing: --- | Windows NT | | Debian | |SMTP - Mailboxs | <--> | running postfix or qmail | | runing Critical Path | | scanning mail for virus | <-> INTERNET | | | and forwading to windows | --- - My mailbox are on Windows NT. What I want is only that a server running on Linux/Debian receive the mails from the internet, check for virus, then forward it to my smtp on Windows. Anyone can help me. Anyone know if it is possible? Thank you for your help. Regards, -- Elcio Mello GNU/Debian - Use it, abuse it, It's Free http://www.rootshell.be/~mello --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Contacting a linux box behind a vicious cable internet firewall?
Here is a neet little app that sounds like it will do what you want. It will connect to a trusted host and then you can connect to a port on that trusted host from a 3rd computer and get redirected back in to the firewall one. Hmm, I probably havn't explained it very well, but check it out anyway. http://www.me.lv/jp/ Hope this helps. - Original Message - From: "Andy Gardner" <[EMAIL PROTECTED]> To: Sent: Saturday, August 17, 2002 1:48 PM Subject: Contacting a linux box behind a vicious cable internet firewall? > > OK. I have a debian machine on a cable internet connection and I want to > ssh into it from the outside. > > Currently can't do it. The Cable ISP blocks ALL ICMP traffic which > certainly doesn't help. > > My first thought is to set the machine up to punch a stunnel connection > through to dedicated server in a fixed location. Then I ssh into that > dedicated server (to a special port #) and that get me connected to the > firewalled box. > > Is this the best way to go? > > The cable ISP refreshes DHCP leases regularly - can stunnel handle the > change in IP # OK? > > Thanks in advance for any suggestions. > > -- > Andrew P. Gardner > barcelona.com stolen, stmoritz.com stays. What's uniform about the UDRP? > We could ask ICANN to send WIPO a clue, but do they have any to spare? > Get active: http://www.tldlobby.com > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
