I need a proxy server that simply records visited web pages and blocks ones I don't want accesed. I can't find any sort of native firewall on the o/s so i downloaded a program called delgate i'm trying to work that, if anyone has already setup something that performs this function I'd love some tips
There's squid for OS/2 compiled by Paul Smedley I think. I should do all what you can imagin from a proxy. I don't know if there's a GUI frontend to configure or if you have to edit the config files manually.
Smartcache (java) is not supported any more, but did run on OS/2. No idea if it can do what you need.
Personally I use Injoy firewall which can block of course, account traffic for different IPs in your lan, show and log connections and much more. Squid runs on this machine too, as proxy for a few special computers in my lan.
There's also a built in firewall in the TCPIP4.3 stack which can be configured with Zampa. But never tried that.
Hey TJTommy!
For the firewall (which is built into the eComStation build you are using), you need to activate the following files/drivers in the config.sys
DEVICE=C:\MPTN\PROTOCOL\IPSEC.SYS
DEVICE=C:\MPTN\PROTOCOL\FWIP.SYS
DEVICE=C:\MPTN\PROTOCOL\CDMF.SYS
DEVICE=C:\MPTN\PROTOCOL\MD5.SYS
DEVICE=c:\mptn\protocol\des.sys
Make sure that you arent adding an extra copy of the line... (one or more might already be installed).
I have a script that will activate and enable the Firewall, SYN Protect Support and read the FWFilters file and re-initialize the firewall...
Also, download FirewallConfig from hobbes... most recent version - same version we are using at the office. That will allow you to do lotsa things with the firewall pretty easily (once you get to understand it).
The help instructions tell you where files need to be placed. If you cant find the info, call me... or bring over the machine and we'll finish it.
-Rob
Thanks guys for the help I'm going to use squid and enable the native firewall.
Hi,
I am using Squid + SquidGuard for extensive web access, logging and filtering . I am using http://hobbes.nmsu.edu/pub/os2/apps/internet/www/server/squid-2.6.stable9-os2.zip which works well as unfortunately the builds that Paul kindly built seem to have a few problems.
If you need any help then please post your questions here!
Regards,
Moby.
Quote from: mobybrick on 2007.07.04, 10:57:18
Hi,
I am using Squid + SquidGuard for extensive web access, logging and filtering . I am using http://hobbes.nmsu.edu/pub/os2/apps/internet/www/server/squid-2.6.stable9-os2.zip which works well as unfortunately the builds that Paul kindly built seem to have a few problems.
If you need any help then please post your questions here!
Regards,
Moby.
Hey Moby,
Do you by any chance know where we can find a (printable) manual for it? Or, is there a .man viewer for OS/2? (Tom searched Hobbes for one with no luck). We did find a site with an online manual for v2.4 (would it suit our needs for 2.6?) - but nothing easily printable for reference.
Thanks,
Rob
Most settings between 2.4 and 2.6 are similar. Only advanced things like transparent mode have changed.
Read the SQUID.CONF file - it will give you an idea of the settings to be changed. To be honest, the most important settings are the location of your cache directory (and run SQUID -z once to build your cache directory) and your bind address (HTTP port).
You can then slowly build up your configuration (such as putting in access controls etc) and test as you go.
I haven't seen a MAN viewer, but there probably is one somewhere. But, as I say, the 2.4 guides are pretty good and most settings have not changed.
Regards,
Moby.
Thanks again Moby! Your help, as always, is very much appreciated!
-Rob
:D
well here's where my project is now i have static ip's working correctly for 2 nic cards on the os2 comp one card ends in 1.5 the other is 5.1 which is going to be connected to my network which as of now is one windows machine, in the routing table i enabled ip fowarding and made a default route to my router ip which ends in 1.1, then i clicked on the "create default net route for given host" button and assigned 5.1 as destination and my sub mask filled in, now the windows machine is set up with static ip that ends in 5.2 with 5.1 as its gateway, the windows machine can ping 5.1 and 1.5 fine and they can ping it but it cannot ping 1.1 and thus get on the internet as the server can HELP!!!!!!!!!!!!!!!!!!!!!!! ???
Hi,
A few things:
1. The OS/2 firewall stack only does port forwarding, NOT network address translation (NAT). This means that you cannot use the OS/2 firewall/IP stack to share the internet amongst multiple workstations (although you could use it to provide internet access to ONE client).
2. SQUID needs to be seen as a logically separate component to the OS/2 native services.
3. SQUID provides HTTP (and tunnelled SSL and FTP over HTTP) web access to multiple clients, running as an application-layer service. As it runs at the application layer, it is of course in a straight-line test slower than a NAT. However, because SQUID is far more efficient than NAT (due to caching of HTTP traffic, DNS lookups and error responses, and also due to pipelined fetching and ICMP round-robin testing) - it more than beats the pants off plain NAT.
4. SQUID allows precise access control - and because it won't forward anything else except HTTP, FTP and HTTPS, there is a lot less security exposure.
5. SQUID's FTP support is NOT a true FTP proxy. You cannot use an FTP client through SQUID. You can, however, use FTP from a web browser (as this is FTP over HTTP).
6. There are some weird work-arounds for bypassing SQUID's protocol limitations by tunnelling other protocols over SSL. These are mainly used as security/anonymization subtefuge, such as in the TOR network.
Here's what I would do in your situation:
a. Research exactly the theories behind SQUID
b. Disable IP forwarding on your OS/2 box. It's a security risk, more than anything else.
c. Install SQUID and configure path locations in SQUID.CONF. Make sure that you then initialize the cache directories by running SQUID -z from the command line. It is far better if this directory is on an HPFS386 or JFS volume.
d. Set SQUID to listen on your internal interface (i.e. the one that is on your Windows clients side, not on the router interface).
e. Make sure that your default route on the OS/2 box is to the router. You should not need to configure the outgoing address of SQUID, but can do if you run into problems.
f. In Incontinent Exploiter on the Windows box, go to Tools -> Internet Options - > Connections -> LAN Settings and configure your Windows machine to use the IP address of your OS/2 machine as its internet proxy. Don't forget to add the correct port number of the SQUID process selected in your SQUID.CONF. You should also disable 'Automatically Detect Settings' in IE unless you have a proxy.pac file around. It is better, if you wish to automatically configure IE, to use Group Policy anyway.
g. Test that you can now access the internet, run Windows update on the Windows machines etc...
h. I would also disable completely access to the default gateway on your Windows machines, and turn off any ability to reach the outside DNS. This will prevent viruses, worms, trojans etc phoning home, unless they use an IP address and HTTP proxy (less likely). SQUID will handle DNS lookups for your IE/Firefox clients.
Hope this helps,
Moby.
This is very good information mobybrick, interesting and useful. I have a minor correction for you though.
Quote from: mobybrick on 2007.07.20, 11:38:41
5. SQUID's FTP support is NOT a true FTP proxy. You cannot use an FTP client through SQUID. You can, however, use FTP from a web browser (as this is FTP over HTTP).
This is not strictly true, at least of the version of Squid I use. While it may have some problems or limitations with FTP, I am using it as an FTP proxy with the NFTP client. Then again, this is the only client (besides wget and web browsers) that works with it, so it could be that NFTP supports this "FTP over HTTP" for compatibility with Squid; although I have not found any other client which claims to support even a "true FTP proxy" either, so I really don't know what that would look like. For both wget and web browser, I specify my squid proxy as an ftp proxy, not as an http proxy. For NFTP iirc it is just set as a proxy, of type Squid.
Quote from: obiwan on 2007.07.20, 20:30:04
This is very good information mobybrick, interesting and useful. I have a minor correction for you though.
Quote from: mobybrick on 2007.07.20, 11:38:41
5. SQUID's FTP support is NOT a true FTP proxy. You cannot use an FTP client through SQUID. You can, however, use FTP from a web browser (as this is FTP over HTTP).
Seeing as you won't take my word for it:
http://linuxsecurity.com/resource_files/firewalls/Bandwidth-Limiting-HOWTO/install.html
Specifically: "Squid is a http proxy with ftp support, not a real ftp proxy. It can download from ftp, it can also upload to some ftp, but it can't delete/change name of files on remote ftp servers."
Quote from: obiwan on 2007.07.20, 20:30:04
This is not strictly true, at least of the version of Squid I use. While it may have some problems or limitations with FTP, I am using it as an FTP proxy with the NFTP client. Then again, this is the only client (besides wget and web browsers) that works with it, so it could be that NFTP supports this "FTP over HTTP" for compatibility with Squid; although I have not found any other client which claims to support even a "true FTP proxy" either, so I really don't know what that would look like. For both wget and web browser, I specify my squid proxy as an ftp proxy, not as an http proxy. For NFTP iirc it is just set as a proxy, of type Squid.
No, sorry, you are mistaken. SQUID only supports FTP over HTTP. All traffic between SQUID and clients is either HTTP or HTTP over SSL. The HTTP streams can be real HTTP, or piggybacked GOPHER, WAIS or FTP. Many other applications now also tunnel lots of other traffic over SSL, to hide their real identity (i.e. TOR).
For a real FTP proxy, see http://www.ftpproxy.org/
Regards,
Moby.
P.S. I have spent 1000's of hours using, debugging and compiling SQUID...
how about other protocols or ports like if my windows machine wants to play starcraft or something will it tunnel the proper port
No, SQUID will not do raw TCP/UDP packet forwarding. Unless your application specifically supports HTTP proxy it will not work.
Unless you can afford the FX Injoy firewall, your only other alternatively is the LinkGuard Solutions firewall. Their website seems to have gone, but I can send you their free firewall if you want (I've never tried it, mind...)
Regards,
Moby
Quote from: mobybrick on 2007.07.21, 13:48:02
Seeing as you won't take my word for it:
http://linuxsecurity.com/resource_files/firewalls/Bandwidth-Limiting-HOWTO/install.html
Specifically: "Squid is a http proxy with ftp support, not a real ftp proxy. It can download from ftp, it can also upload to some ftp, but it can't delete/change name of files on remote ftp servers."
That seems consistent with my experience. A more careful reading of my previous post would find no indication that I actually disbelieve the technicalities of your word on the matter.
QuoteNo, sorry, you are mistaken. SQUID only supports FTP over HTTP.
I do not read in my post where I said this is not the case. I said, in answer to your statement that an FTP client cannot be used with Squid, that I use it with 3 different clients. On my network, Squid connects to FTP, not HTTP, servers, from clients set to use proxies for FTP, not HTTP. In Firefox this is the "FTP Proxy" line of the Network Settings configuration. For wget this is the "ftp_proxy" variable, and for NFTP this is "firewall-host" setting, in combination with the "firewall-type" setting of 5, for Squid. This is not something I can be mistaken about because it is my first-hand personal user experience. Whatever the technical way it works, it is how I use it. So while most FTP clients do not seem to support using it this way, or, put another way, Squid does not technically do what would be required to use them as such, I do use
some FTP clients with Squid as a proxy, therefore the statement "You cannot use an FTP client through SQUID" is not strictly true, from a user standpoint.
QuoteFor a real FTP proxy, see http://www.ftpproxy.org/
Ah, thanks. I could see how that might be useful. Not as conveniently transparent as Squid, but would let you do things Squid can't, without requiring any special support in the clients. For most of what I do, Squid seems a better choice, and my advice that it can work well for others as I described, holds true.
Unless we are careful, we could end up confusing and bewildering the original poster, or anyone else reading this thread...
You said:
Quote from: obiwan on 2007.07.20, 20:30:04
This is very good information mobybrick, interesting and useful. I have a minor correction for you though.
Quote from: mobybrick on 2007.07.20, 11:38:41
5. SQUID's FTP support is NOT a true FTP proxy. You cannot use an FTP client through SQUID. You can, however, use FTP from a web browser (as this is FTP over HTTP).
This is not strictly true, at least of the version of Squid I use.
And then you said you "That seems consistent with my experience. A more careful reading of my previous post would find no indication that I actually disbelieve the technicalities of your word on the matter" when you do seem to take a different view to mine, www.squid-cache.orgs, or linuxsecurity.com.
SQUID only talks HTTP to a client - so any Windoze software must do HTTP transfers to do this (or use the SSL 'Connect' method). The 'average' Windows program, requiring direct FTP access to the web, will NOT work with Squid.
So, for the average user - as we are not in a position to test all of their requirements - they should NOT plan on their FTP access working with Squid - and just be pleasantly suprised if it does!
Additionally, Squid can support either passive or non-passive transfers - but not both at once....
Just trying to be pragmatic and work on worst case scenario - as well as trying to explain what Squid does under the covers...
Regards,
Moby.
Quote from: mobybrick on 2007.07.23, 17:10:36
Unless we are careful, we could end up confusing and bewildering the original poster, or anyone else reading this thread...
I could not agree with you more. I think that is the trouble with getting too technical in a thread about a usage question.
Do you understand the difference between something being "not strictly true" and "disbelieving the technicalities" of something?
For something to be not
strictly true, it needs only to have a single case where something about it does not hold true. It does not mean that everything about it is false, so the use of the phrase "not strictly true" implies that there is only a minor defect; and if that is missed, the phrase "minor correction" found in the opening line of my original post should help in catching the intent. The example I give of my usage is not to challenge you to a lengthy technical argument, but to offer a real option to interested parties which is otherwise excluded by your advice. That only means that the statement "You cannot use an FTP client through SQUID" is in certain cases not true, nothing more.
I follow up the example with language such as "then again," "it could be," and "I really don't know," attached to each mention of the underlying technicalities, which strongly implies that I have no certainty about them; which thus carries the implication that I have no basis to disbelieve what you say about them. What is more, nothing I said about them contradicts what you had said about them.
Notice here I refer to technicalities, which is distinguished from usage. Usage is what people use a thing for, while technicalities are the technological details which make it possible. For example, "FTP over HTTP" is a technicality, whereas "use the NFTP client with Squid" is a usage.
When I said, "That seems consistent with my experience," it was not a contradiction to my previous statement, but a confirmation that certain FTP clients can be used with Squid to upload and download files, not delete or rename them, as you quoted from linuxsecurity.com. Notably, this is consistent with my original statement that Squid may have some problems or limitations with FTP, and that some FTP clients can use it.
Quoteyou do seem to take a different view to mine, www.squid-cache.orgs, or linuxsecurity.com.
I do not take a view at all, so that is a mischaracterization. I have a different usage from you, and as I said my experience is consistent with your quote of linuxsecurity.com, so I do not differ with it. My usage is the same as icemantc6's original stated intent, to "record visited web pages and block ones I don't want accessed," a purpose for which Squid works excellently for me with select FTP clients.
QuoteThe 'average' Windows program, requiring direct FTP access to the web, will NOT work with Squid.
Or 'average' FTP program for OS/2 or any platform. I specifically said in my original post that only wget, NFTP, and web browsers will work.
What exactly am I mistaken about? Are you arguing that I am mistaken in how I am using Squid, or that I am using it incorrectly, or that I am imprudent to suggest to others that it is possible to use it the same way I do? Or simply that you know more about Squid than I do? I am happy to agree with you on that last point.
Quotetrying to explain what Squid does under the covers...
An approach which seems a bit too technical even for me, though the information is duly noted and appreciated.
ok so my proxy is up and running squid turned out to be amazing one problem though, one of the reasons this server is needed is to block web sites i tried doing that using the acl tags using the urlregex urlpath regex and none seem to work, i have to block multiple web sites but for now i want to block myspace to get a feel of how to do it
Quote from: icemantc6 on 2007.07.23, 21:42:45
ok so my proxy is up and running squid turned out to be amazing one problem though, one of the reasons this server is needed is to block web sites i tried doing that using the acl tags using the urlregex urlpath regex and none seem to work, i have to block multiple web sites but for now i want to block myspace to get a feel of how to do it
Great that you have made some progress!
Try the following. Remember that the allow/deny statements are processed in order, so if you had something like 'http access allow all' at the beginning, any deny statements would never be processed....
acl test_deny url_regex [-i] ^http://www.myspace.com
#Recommended minimum configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
http_access deny test_deny
# insert any other allow statements here
http_access allow localhost
http_access allow our_networks
# And finally deny all other access to this proxy
http_access deny all
It's a good idea to always finish with the http_access deny all statement.
Let me know how things go!
Regards,
Moby.
Quote from: obiwan on 2007.07.23, 19:52:43
Quote from: mobybrick on 2007.07.23, 17:10:36
Unless we are careful, we could end up confusing and bewildering the original poster, or anyone else reading this thread...
I could not agree with you more. I think that is the trouble with getting too technical in a thread about a usage question.
Do you understand the difference between something being "not strictly true" and "disbelieving the technicalities" of something?
Oh dear. Now your uncareful use of language could easily be taken to imply that I'm stupid. I avoided the personal comments. You really have to have the last word don't you. Actually, I think I've been quite patient. A quick Google search produces lots of information that contradicts pretty much everything you say...
Quote from: obiwan on 2007.07.23, 19:52:43
For something to be not strictly true, it needs only to have a single case where something about it does not hold true. It does not mean that everything about it is false, so the use of the phrase "not strictly true" implies that there is only a minor defect; and if that is missed, the phrase "minor correction" found in the opening line of my original post should help in catching the intent. The example I give of my usage is not to challenge you to a lengthy technical argument, but to offer a real option to interested parties which is otherwise excluded by your advice. That only means that the statement "You cannot use an FTP client through SQUID" is in certain cases not true, nothing more.
Anything which uses anything additional to the FTP protocol, is, by definition **not** a plain FTP client. We've already established that SQUID only talks HTTP. Therefore, the statement 'You cannot use an FTP client through SQUID' is correct. Only timewasters would go and find something that is not *just* an FTP client (i.e. it talks something else as well) and say it works....
Quote from: obiwan on 2007.07.23, 19:52:43
I follow up the example with language such as "then again," "it could be," and "I really don't know," attached to each
If you really don't know, why waste everyones time trying to make out that you do and then confuse everything?
Quote from: obiwan on 2007.07.23, 19:52:43
Or 'average' FTP program for OS/2 or any platform. I specifically said in my original post that only wget, NFTP, and web browsers will work.
Funning, 'coz according to the NFTP documentation, SQUID is listed as being an 'HTTP' proxy with severe limitations. They even recommend patching the SQUID code so that transfers are reliable.
See http://www.ayukov.com/nftp/firewall.html
5. HTTP proxy (Squid)
Currently, only Squid and Netscape SuiteSpot server are supported. You have to specify `firewall-host' and port (typically 3128 for Squid). Both Squid 1.x and 2.x are supported; my tests were done on 1.1.22 and 2.1-RELEASE. For best results it is recommended (but of course not necessary) to apply a patch to Squid sources before compiling it. The patch is available from ftp://ftp.ayukov.com/pub/nftp; instructions are inside. It will force Squid to report file size in bytes for NFTP instead of kilobytes; this makes file sizes in NFTP precise instead of rounded. Restarting transfers through Squid is not yet supported, and some features are not available via Squid; these include making directories, renaming and deleting files. Uploading and authentication are supported since NFTP version 1.60. All transfers are made in binary mode. With Squid, there's no such thing as 'permanent connection to server', and you can't verify connection aliveness or send verbatim commands to server
Yup, as I guessed, NFTP is working exactly as I said it would be....
Quote from: obiwan on 2007.07.23, 19:52:43
An approach which seems a bit too technical even for me, though the information is duly noted and appreciated.
I wasn't the one on an ego trip here. I only came to this board to help people. Unfortunately, most people's queries here are of a technical nature. Don't you think it requires a technical approach to solve a technical problem?
*************************** SUMMARY FOR ALL THOSE BORED ***************************
SQUID may support your FTP client, it may not. It is not intended as a real FTP proxy. This means that no-one can guarantee anything but a web-browser to work. Also, the developers routinely make changes to the code and only test these against web browsers. If your FTP client does work, great. If it does not, then you will need to find another way. Unfortunately, SQUID is only a HTTP proxy (and SSL tunnel) and HTTP caching/proxying is the primary design goal of the developers - FTP support is only there for web browser *download* usage. So, even if it does work, only extremely old browsers will allow you to upload via FTP through SQUID.
So, if anyone says that they can't get their FTP client to work with SQUID - but hear that others may have got theirs to work in a blue moon - look to see if an option for 'HTTP proxy' support is available. If there is not, then probably little can be done. Others may find that only FTP sites that accept anonymous credentials will work - another possible limitation of the SQUID design.
Lastly, there are *real* FTP proxy solutions available, and these are free. If you need full FTP support (i.e. not just for web browser downloads) then it may be a good idea to install one of these. Alternatively, other solutions such as the DELEGATE proxy, or a NAT solution may suit you.
Best regards to everyone,
Moby.
Quote from: mobybrick on 2007.07.24, 00:03:21
Oh dear. Now your uncareful use of language could easily be taken to imply that I'm stupid. I avoided the personal comments. You really have to have the last word don't you. Actually, I think I've been quite patient.
All personal and irrelevant. I'm not going there.
QuoteAnything which uses anything additional to the FTP protocol, is, by definition **not** a plain FTP client. We've already established that SQUID only talks HTTP.
My use is for FTP requests to FTP servers, not HTTP requests to web servers.
QuoteTherefore, the statement 'You cannot use an FTP client through SQUID' is correct.
It is correct, but not when taken in a
strict sense. That is why the word
strict exists.
QuoteOnly timewasters would go and find something that is not *just* an FTP client (i.e. it talks something else as well) and say it works....
If that is the case, I use Squid in a way that wastes time; but it is how I do it. I thought the information might be useful, but apparently it is controversial. I wish you had simply said it is a poor recommendation if that is what you meant. Since the entire content of what I tried to contribute is what I have done, it cannot be contradicted by Google searches.
QuoteIf you really don't know, why waste everyones time trying to make out that you do and then confuse everything?
I did not say or "make out" that I know about the technicalities involved. As was just discussed I implied otherwise. I said that I use Squid in a way that is in some contexts described as an FTP proxy, because I thought it might be helpful. I am sorry that turned out to be confusing.
QuoteYup, as I guessed, NFTP is working exactly as I said it would be....
I am glad reading the documentation satisfies you that the way I use it is consistent with your technical understanding. I don't see where that or anything you are quoting contradicts what I said.
QuoteUnfortunately, most people's queries here are of a technical nature. Don't you think it requires a technical approach to solve a technical problem?
Absolutely, but what I understand you to be doing is arguing with me and telling me I am wrong about technical details I did not really make a statement about. It is interesting information, but doesn't really make any difference to how I use Squid. I did thank you for explaining about what a true FTP proxy is. You did help me to understand better, but I do not plan to replace Squid with one because it works so well for me. I do have some limitations, but I do not have a problem with it. As I acknowleged it was limited, I don't think my suggesting it to others with that caveat was out of line.
But judging by the amount of text and emotion that resulted, maybe it turned out to be a mistake.
Quote from: mobybrick on 2007.07.24, 00:03:21
If you really don't know, why waste everyones time trying to make out that you do and then confuse everything?
There is, of course, a better way to answer this. That is that if one (such as myself in this case) posts something to a forum with a tenor of ignorance, it is usually with the invitation to be set straight on the matter.
You did that when you pointed me to the ftpproxy site. The documentation there was very cursory in explaining how it worked so it took me a few minutes to understand. That is why I came back, thanked you, and posted more clearly and succinctly than its own documentation why it might be a better choice in some cases.
There is of course no requirement that anyone set me straight because this is a friendly community forum where we help out of sheer kind volunteerism. But if one is to do it, it should be to correct what I actually said, or tell me where I am wrong or misunderstanding. That is why when you told me I am mistaken about things I did not say, and did not accept the thing I really did say, I followed up with more explanation of my previous text. That certainly can end up wasting time, which is why it is generally good practice to read and write the text carefully. I thought I had done that, and there seems to be evidence for that since I am able to point to the original text to support every clarification, but apparently it was not clear enough; so I am sorry I injected myself into this thread.
I think your "For the Bored" text sums up the facts well enough, so I'll exit here. If you feel any desire to tell me more about your observations of my mistakenness and uncarefulness and other flaws I heartily welcome you to send them to me privately.
Quote from: obiwan on 2007.07.24, 01:13:11
Quote from: mobybrick on 2007.07.24, 00:03:21
Oh dear. Now your uncareful use of language could easily be taken to imply that I'm stupid. I avoided the personal comments. You really have to have the last word don't you. Actually, I think I've been quite patient.
All personal and irrelevant. I'm not going there.
[/quote]
You started it... But I am sorry if we wound each other up.
Quote from: obiwan on 2007.07.24, 01:13:11
Quote from: mobybrick on 2007.07.24, 00:03:21
Anything which uses anything additional to the FTP protocol, is, by definition **not** a plain FTP client. We've already established that SQUID only talks HTTP.
My use is for FTP requests to FTP servers, not HTTP requests to web servers.
[/quote]
Actually, we weren't here to talk just about your requests. My responses were to help the original poster. We've already established that NFTP is *not* just a plain FTP client (because it also can use HTTP GET) and neither is wget.
Quote from: obiwan on 2007.07.24, 01:13:11
Quote from: mobybrick on 2007.07.24, 00:03:21
Therefore, the statement 'You cannot use an FTP client through SQUID' is correct.
It is correct, but not when taken in a strict sense. That is why the word strict exists.
[/quote]
But I never used the word 'strict.'
Quote from: obiwan on 2007.07.24, 01:13:11
Quote from: mobybrick on 2007.07.24, 00:03:21
Only timewasters would go and find something that is not *just* an FTP client (i.e. it talks something else as well) and say it works....
If that is the case, I use Squid in a way that wastes time; but it is how I do it. I thought the information might be useful, but apparently it is controversial. I wish you had simply said it is a poor recommendation if that is what you meant. Since the entire content of what I tried to contribute is what I have done, it cannot be contradicted by Google searches.
[/quote]
Wouldn't it be better to say that there is a possibility that a person's FTP client may support more than just FTP and that it may work? Rather than saying that it works for you and therefore must work for everyone? I'd still wager that most FTP clients will NOT work through SQUID.
I do find that sometimes an assumption as to how things work can cause great problems; I run SQUID on OS/2 with thousands of clients, and people 'promising' things that cannot be done is a cause of great frustration. Taking a bit of time to fully understand how things are working and therefore what is available prevents frustration for everyone...
Quote from: obiwan on 2007.07.24, 01:13:11
plan to replace Squid with one because it works so well for me. I do have some limitations, but I do not have a problem with it. As I acknowleged it was limited, I don't think my suggesting it to others with that caveat was out of line.
What limitations? Anything we can help with?
Quote from: mobybrick on 2007.07.24, 11:16:28
What limitations? Anything we can help with?
Thank you, no. Just the limitations we described. I can only use NFTP for uploads, and I'm not crazy about NFTP. Trying to delete produces weird behavior. It is acceptable to me for my purposes.
I did intend to exit this, believe it or not.
Quote from: mobybrick on 2007.07.24, 11:16:28
You started it...
I haven't said anything about you or myself, other than what I have done with regard to the topic and what we have said here. My question about your understanding of my words was in response to the way you were representing them. I cannot imply things that I cannot know, and I do not know you.
QuoteActually, we weren't here to talk just about your requests.
My purpose of mentioning my use is to clarify that Squid will talk to FTP servers, and in this context it is in a sense an FTP proxy, even if not a "true FTP proxy."
QuoteWe've already established that NFTP is *not* just a plain FTP client (because it also can use HTTP GET) and neither is wget.
From the NFTP documentation (http://www.ayukov.com/nftp/features.html):
wget can also download via HTTP though while NFTP cannot
NFTP is not an ordinary FTP client, but it is not for purposes other than FTP.
QuoteBut I never used the word 'strict.'
I did. I said the statement is not strictly true, and you said I am mistaken, which means that what I said is untrue. Saying that a statement is untrue is logically equivalent to stating the opposite of the statement, which would be, "It is strictly true."
Quote
Wouldn't it be better to say that there is a possibility that a person's FTP client may support more than just FTP and that it may work? Rather than saying that it works for you and therefore must work for everyone?
That would be acceptable, but what I said was more precise, that NFTP, wget, and web browsers work, and I have found nothing else that does. That makes it explicit what works and what doesn't. These clients work not because I am the one using them but because they are compatible, so they will work for anyone. In contrast, the wording you give seems to hint that it is some function other than FTP that works. So no, I don't think that would be better.
Quote
I'd still wager that most FTP clients will NOT work through SQUID.
That has been made clear by both of us several times now already. I never said this was not the case.
QuoteI do find that sometimes an assumption as to how things work can cause great problems; I run SQUID on OS/2 with thousands of clients, and people 'promising' things that cannot be done is a cause of great frustration. Taking a bit of time to fully understand how things are working and therefore what is available prevents frustration for everyone...
Agreed. I appreciate your explaining how it is that NFTP works when others do not. I don't think, though, that avoiding frustration is so paramount as to make necessary the exclusion of all options that have a possibility of it. As long as we are clear about the limitations, it is legitimate to consider even such unconventional options as OS/2 and eComStation.
Dear reader,
C'mon, this has got to be a wind-up. I'm half expecting Dave Letterman to appear from behind somewhere! Lighten up!
I'm sorry Obiwong, but you seem to be wound up on arguing about language semantics, implying people (myself) are 'stupid' because they don't understand the differences in simple bits of language, and picking holes in choice of words rather than having a real technical discussion based on fact...
SQUID supports HTTP only. This means that web browsers can download through SQUID, as this is what SQUID is designed to provide. Only extended FTP clients that support HTTP methods (i.e. a web-browser) will work. Most FTP (only) clients will not work. None of the FTP-only tools supplied with OS/2 will work through SQUID. Period. Tools like NFTP and WGET use SQUID as an HTTP proxy, and functionality is limited, although WGET works better for downloads and it is is designed to use HTTP properly.
If you are far more worried about whether this is strictly true (which it is), or whether this is 'Saying that a statement is untrue is logically equivalent to stating the opposite of the statement, which would be, "It is strictly true."' then I'd suggest that you have bigger worries than FTP to deal with.
Incidentally, it's worth reading http://www.squid-cache.org/mail-archive/squid-users/200312/0122.html to see the progress thus far on adding delete support to SQUID. I don't think it has yet been implemented, although you could try adding DELETE to the HTTP extension_methods in the SQUID.CONF.
Now, come on out Dave!
Regards,
Moby.
That entire response was ad hominem and personal and not worth a reply, except the tip about adding delete to Squid, so I'll watch for that, thanks.
Hi,
Ad hominem and personal obviously mean pretty much the same thing, but I won't beat you up about repeating yourself...
I actually was trying to be a bit light-hearted and do appreciate the ideas behind
some of the points you have made. But I've also spent a lot of time in the last few months trying to support SQUID and am rather fed up of people making assumptions about what it will do, rather than reading the (extensive) documentation first. Nothing I've stated is factually incorrect and all of it was designed to be nothing but helpful...
See you around...
Regards,
Moby.
Quote from: obiwan on 2007.07.24, 21:00:51
That entire response was ad hominem and personal and not worth a reply, except the tip about adding delete to Squid, so I'll watch for that, thanks.
Quote from: obiwan on 2007.07.24, 19:49:43
As long as we are clear about the limitations, it is legitimate to consider even such unconventional options as OS/2 and eComStation.
Though they may seem like unconventional options (eCS/Warp), we are finding that none of our clients care what OS is running on their server as long as
- They dont have to touch it, look at it, reboot it, scan it for viruses, upgrade it on a continuous cycle
- They dont need to pay an IT guy to come in to do the above on a monthly basis
For that, we find eCS an optimal solution. Linux may do as well, though personally I have found the current threading model in eCS to be better... while that is supposed to be changing with the kernel threading changes in Linux, those changes are still kinda experimental. In addition, installing eCS seems a little easier. Configuring it to manage all levels of hosting and serving other than MS Exchange and similar tools (which none of our clients use) is also easy. Makes a great firewall, file server, ftp server, mail server, web server, proxy server, DDNS server, DHCP server, print server, the list goes on... and all of which are easily REXX scriptable to one extent or another (through callable REXX scripts called directly through the app/daemon, or like in the case of the Firewall, by having a REXX script rewrite rules and configuration info, and telling the firewall to reload it's configuration and rules).
eCS is easy to secure, all aspects of serving are well documented, and updates are rarely if ever needed. On today's hardware it flies - even when running multiple server daemons - unlike Windows. And using highly threaded apps (like Lotus Domino GoWebserver) it outperforms any PC based OS I have ever tested such things on. And each new license we purchase helps fund further development for eCS.
As for the rest of where this thread is going (the FTP debate), please guys, lets keep it civil. Tom (icemantc6) wasn't that concerned with FTP as it is being blocked (by the firewall) anyway. Letting him know that the support is non-standard is helpful in the event (which is possible) that it needs to be unblocked and supported later. You both seem to already agree as to Squid's FTP functionality and/or lack thereof and seem to be just debating semantics right now.
That can lead to this thread becoming an
endless debate on semantical issues -
where instead - this thread
can be very informative and helpful (thanks to both of your wonderful input) to anyone else who in the future wishes to use Squid as a proxy server on eCS.