headers
Richard Nairn | 1 Aug 2004 03:14
Picon

Re: how to block more then 10,000 site with SQUID ?

Check out www.squidguard. It uses squid, and is an external program which  
decides if a domain,url, regex should be allowed or not. I use it for a  
few sites with a a blacklist and it works well, and fast...

On Thu, 29 Jul 2004 12:40:51 +0600, Kev <savage-garden <at> hanikamail.com>  
wrote:

> hi,
>
> i have a site list that i need to block with squidl this list is on a
> TXT files, it got more then 10000 domains, how can i do this with SQUID  
> ??
>
> plz help
> ---------------------------------------------
> # [Misc Add-ons][A - Z]
>   abcsearch.com
>   admin.abcsearch.com
>   www3.abcsearch.com #[Browseraid]
>   www.abcsearch.com
>   abc517.net #[Trojan.Mitglieder.H]
>   acestats.com
>   www.acestats.com
>   actualnames.com #[Parasite.ActualNames]
>   www.actualnames.com
>   ad-up.com
>   www.ad-up.com
>   adatom.com
>   aesp.adatom.com
>   adbest.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ahsan Ali | 1 Aug 2004 22:48
Picon

Re: ip route refresh

Can you give some specific examples?

I use linux extensively for routing and have never come across this.

Show us exactly what you're doing and the route tables when you do it.

-Ahsan

On Sat, 31 Jul 2004 10:13:06 +0200, Luca Ferrari <fluca1978 <at> infinito.it> wrote:
> On Saturday 31 July 2004 00:34 Glynn Clements's cat walking on the keyboard
> wrote:
> 
> > Luca Ferrari wrote:
> > > I've noted on different system that when an ip route changes, the kernel
> > > keeps the old one in a cache (I suppose) for a while. For example, if in
> > > you /etc/hosts you have an entry:
> > > 192.168.1.201 fluca fluca
> > > and ping fluca it will try to connect to 192.168.1.201.
> > > Now if you change the address and immediatly reping it, it will try again
> > > the old host for a while. After a minute the system should be able to use
> > > the new address. This also applies to routes.
> > > Is there a way to force a cache-clear, thus modifications are immediatly
> > > visible?
> >
> > 1. What does this have to do with routing? Unless I'm misunderstanding
> > the above, this is a name-service issue.
> >
> 
> No, it's not, since I've experienced it also using direct addresses. I mean,
> if you ping 192.168.1.201 the packets will follow a particular way. If you
(Continue reading)

Permalink | Reply | 2 comments |
headers
Luca Ferrari | 2 Aug 2004 14:10
Picon
Favicon
Gravatar

Re: ip route refresh

On Sunday 01 August 2004 22:48 Ahsan Ali's cat walking on the keyboard  wrote:

> Can you give some specific examples?
>
> I use linux extensively for routing and have never come across this.
>
> Show us exactly what you're doing and the route tables when you do it.

Well, I've noticed it first when I changed my router policies. From a computer 
I was telnetting a remote host on another subnet. The subnet was reached thru 
a Linux gateway connected to two routers (call them R1 and R2). In a first 
test R2 was down, so all the traffic was traveling over R1. When R2 was up, 
the traffic to the above subnet was redirected to the R2 router (i.e., I 
changed the 'route' policy of the gateway). Nevertheless, for a couple of 
minutes the traffic was going over R1.
Another issue I've noticed was an error on the /etc/hosts (different machine): 
I wrongly wrote  the address of an host, thus pinging it was a real ping to 
another machine. I correct the entry and re-do ping, but it was still pinging 
the wrong host. After a minute everything was working fine, but immediately 
it was not. I believe it could be an arp cache problem, as you suggested me.
Thanks,
Luca
--

-- 
Luca Ferrari,
fluca1978 <at> infinito.it
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luca Ferrari | 3 Aug 2004 09:52
Picon
Favicon
Gravatar

problem with smbumount and cron

Hi,
I've got the following simple script which copies a file thru samba between 
two linux machines. The script is executed within cron:

#!/bin/bash
FILE_NAME=/vol1/sys/tmp/fatturato.html
SHARE=web_privato
IP=192.168.1.7
MOUNT_POINT=/mnt/firewall

/usr/bin/smbmount //${IP}/${SHARE} ${MOUNT_POINT} -o ip=${IP},guest
if test $? -eq 0
then
    cp ${FILE_NAME} ${MOUNT_POINT}
    /usr/bin/smbumount ${MOUNT_POINT}
fi

Nevertheless, the mount point is never unmounted if the script runs thru cron, 
while it is rightly unmounted if launched by an interactive user. I'm running 
it on a redhat 6.2 and a suse 9.0 with the same problem. Any thoughts?

Luca

--

-- 
Luca Ferrari,
fluca1978 <at> infinito.it
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lei Yang | 3 Aug 2004 19:43

Encrypted Loopback Filesystem

Hello,

I am trying to play around loopback device and want to set up an
encrypted loopback filesystem. I did the following things:

1. losetup -e serpent /dev/loop0 /etc/crypt
/ect/crypt: Is a directory

So I tried: losetup -e serpent /dev/loop0 /etc/cryptfile and this time
cryptfile is a plain txt file.

Enter passwd...

2. mkfs -t ext2 /dev/loop0
3. mount -t ext2 /dev/loop0 /mnt/crypt

After this, how do I verify that anything happened that has enabled
encryption? I can't understand where the encrypted filesystem lies in
here:( Plus, when we say 'encrypted', which file is on earth encrypted?
Is that files and data in /mnt/crypt are encrypted form of
/etc/cryptfile? Really confused.

TIA!

Lei 

-
To unsubscribe from this list: send the line "unsubscribe linux-config" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tony Gogoi | 3 Aug 2004 18:03

Reverse lookup problem


Hello,

Our mail server uses "sendmail" and DNS server used "bind".

We have a problem with sending mail to a site X which returns error
"Sender IP must resolve". So, that means their mail server could not
reverse map our mail server's IP address to fully qualified domain name.

On our DNS server, I can correctly reverse map our mail server's IP
address:
dig -x <our mail server ip address>

The answer section returned is correct.

However, on an external network,
dig -x <our mail server ip address>
does NOT return an an answer section.

Instead, it only returns an AUTHORITY section stating our service
provider's IP address?

Does this mean our service provider doesn't have a "glue record". Or is it
possible "dig" is not sufficient to test reverse lookup and the problem is
at our end ?

Grateful for any help.

Thanks,
Tony
(Continue reading)

Permalink | Reply | 5 comments |
headers
Scott Taylor | 3 Aug 2004 18:22

Re: Reverse lookup problem


Tony Gogoi said:
>
> Hello,
>
> Our mail server uses "sendmail" and DNS server used "bind".
>
> We have a problem with sending mail to a site X which returns error
> "Sender IP must resolve". So, that means their mail server could not
> reverse map our mail server's IP address to fully qualified domain name.
>

As long as there is a reverse lookup it should be OK.  Try 'host IP' to
see if you have a reverse lookup, if not, ask your ISP to add one. 
Doesn't even have to resolve to your domain name, just as long as it
resolves.

--
Scott

-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Tony Gogoi | 3 Aug 2004 18:30

Re: Reverse lookup problem


Hi Scott,

>
> As long as there is a reverse lookup it should be OK.

But then, the "dig" query does not return the mail server name. Only
mentions the authority is our network provider.

> Try 'host IP' to
> see if you have a reverse lookup, if not, ask your ISP to add one.
> Doesn't even have to resolve to your domain name, just as long as it
> resolves.

>
"host ip" returns
Host ip. not found: 3(NX DOMAIN)

Thanks,
Tony

> --
> Scott
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Adam Lang | 3 Aug 2004 18:49

Re: Reverse lookup problem

The problem is, his internal name server is NOT his public name server.
That is why he can dig internally, but externally he can't.

Tony, to answer your question, yes, the problem is your ISP needs to have a
PTR record setup for your mail server.
----- Original Message ----- 
From: "Scott Taylor" <scott <at> dctchambers.com>
To: <linux-admin <at> vger.kernel.org>
Sent: Tuesday, August 03, 2004 12:22 PM
Subject: Re: Reverse lookup problem

>
> Tony Gogoi said:
> >
> > Hello,
> >
> > Our mail server uses "sendmail" and DNS server used "bind".
> >
> > We have a problem with sending mail to a site X which returns error
> > "Sender IP must resolve". So, that means their mail server could not
> > reverse map our mail server's IP address to fully qualified domain name.
> >
>
> As long as there is a reverse lookup it should be OK.  Try 'host IP' to
> see if you have a reverse lookup, if not, ask your ISP to add one.
> Doesn't even have to resolve to your domain name, just as long as it
> resolves.
>
> --
> Scott
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tony Gogoi | 3 Aug 2004 19:26

Re: Reverse lookup problem

On Tue, 3 Aug 2004, Adam Lang wrote:

>
> Tony, to answer your question, yes, the problem is your ISP needs to have a
> PTR record setup for your mail server.

You mean, our ISP needs to have a PTR record setup for our DNS server
(rather than our mail sevrer) right ?

From an external network,

dig <our mail server name>

correctly prints the IP address of our mail server and correctly prints
the DNS server names in the authority section from an external network.

Its

dig-x <our mail server IP address>

on an external network which is the problem.

Thanks,
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |

Gmane