Hi!
"Gabor HALASZ" írta 2008-12-15 20:24-kor:
> Nem, tobb rendbeli problema van, azt hiszem, csak interface-re
Ahogyan az elméleteddel is.
> bindelessel oldhato meg. Az alapeveto problema az, hogy routing az
> ~layer3, a tcp meg ~layer4, igy a routingnak mindegy, hogy http vagy
Mindegy lenne,
Szima Gábor wrote:
> Sziasztok!
>
> Van arra standard megoldas, hogy a make mindig annyi szalon forditson,
> amennyi proci/mag van az adott gepben?
>
> Vagy buveszkedni kell (/proc-bol kisakkozni, es -j utan parameterkent
> atadni)?
>
en valahol ugyolvastam, h ezt a Makefile-nak is tamogatnia
On Mon, 15 Dec 2008, [ISO-8859-1] Kovács Attila wrote:
> Miért csak a procik számától függne a make hatékonysága?
Nem kitetel, csak beugrott a -j kapcsolo (ugy 1x evvel ezelottrol ;),
mostansag pedig divatosak lettek a multi-core procik, ugyhogy miert ne.
> Én inkább ezt használnám ha már , a
On Mon, 15 Dec 2008 22:43:46 +0100
Kovács Attila wrote:
> Én inkább ezt használnám ha már , a jobs meg lehet unlimited.
>-l [load], --load-average[=load]
Nem értek egyet. Mást jelent egy 1 processzoros gépen a 4-es load
(pl.) , meg mást jelent egy 4 processzoros gépen.
--
Üdvözlettel,
Szima Gábor írta:
> Sziasztok!
>
> Van arra standard megoldas, hogy a make mindig annyi szalon forditson,
> amennyi proci/mag van az adott gepben?
>
> Vagy buveszkedni kell (/proc-bol kisakkozni, es -j utan parameterkent
> atadni)?
>
Izé.
Miért csak a procik számától függne a make hatékonysága
Sziasztok!
Van arra standard megoldas, hogy a make mindig annyi szalon forditson,
amennyi proci/mag van az adott gepben?
Vagy buveszkedni kell (/proc-bol kisakkozni, es -j utan parameterkent
atadni)?
-Sygma
_
Gabor HALASZ wrote:
> Nem, tobb rendbeli problema van, azt hiszem, csak interface-re...
Ha nem, hát nem ;-(
Köszönöm a segítséget, útmutatást.
Üdv: Kanyó Miklós
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/
linux wrote:
> Gabor HALASZ wrote:
> >Nem is fog.Mire az output chainben a mangle table sorra kerul, mar tul
> >van a routing decision-on, es onnan meg par lepes a nat table, plane az
> > postrouting chain.
>
> Értem én amit mondasz.
> Meg lehet ezt a problémát oldani ip/iptables segítségével?
Gabor HALASZ wrote:
>Nem is fog.Mire az output chainben a mangle table sorra kerul, mar tul
>van a routing decision-on, es onnan meg par lepes a nat table, plane az
> postrouting chain.
Értem én amit mondasz.
Meg lehet ezt a problémát oldani ip/iptables segítségével?
__
> De a kérdés marad miért szűri ki az egyik esetben és miért nem a másikban???
Az elsőnél az url-ben is és a filenévben is van "skype" szó, a másodiban
nem.
Bár az url_regex elvileg az egész url-re vonatkozik.
Sztem nézd meg a dstdomain, és
az urlpath_regex részeket is.
S.Z:
PÁSZTOR György wrote:
> Hi!
>
> "Gabor HALASZ" írta 2008-12-15 16:58-kor:
>>> > iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j
>>> MASQUERADE
>>>Sajnos ez sem működik.
>> Nem is fog. Mire az output chainben a mangle table sorra kerul, mar tul
>> van a routing decision-o
Hi!
"Gabor HALASZ" írta 2008-12-15 16:58-kor:
> > > iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j
> > MASQUERADE
> >Sajnos ez sem működik.
>
> Nem is fog. Mire az output chainben a mangle table sorra kerul, mar tul
> van a routing decision-on, es onnan meg par lepes a
Erdei-Gulyás Ferenc wrote:
> Gabor HALASZ írta:
>> atverni is igen konnyu az acl url_regex-et, pl egy ut8 kodolasu
>> url-lel.
>> Hasznalj squidguard-ot, hogy lehet hozza kesz listat toltikezni, havi
>> par dollarert meg frissitik is.
>>
> Köszönöm! Kipróbálom. Sőt 99% hogy használni is fogom.
linux wrote:
> Kedves Gyur!
>
> > iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j
> MASQUERADE
>Sajnos ez sem működik.
Nem is fog. Mire az output chainben a mangle table sorra kerul, mar tul
van a routing decision-on, es onnan meg par lepes a nat table, plane az
postrou
linux wrote:
> Kedves Gyur!
>
> > A postfix-nek emlékeim szerint meg lehet mondani, mely interfészekre
>qmail-em van.
>
http://rno-consultores.com/mail/qmail/qmail-1.03_outgoingips.patch
--
Gabor HALASZ
_
linux lista - linux@mlf.
Gabor HALASZ írta:
> atverni is igen konnyu az acl url_regex-et, pl egy ut8 kodolasu
> url-lel.
> Hasznalj squidguard-ot, hogy lehet hozza kesz listat toltikezni, havi
> par dollarert meg frissitik is.
>
Köszönöm! Kipróbálom. Sőt 99% hogy használni is fogom.
De a kérdés marad miért szűri ki a
Erdei-Gulyás Ferenc wrote:
>
> A squid.conf -ban a köv módon oldom meg a szűrést:
> acl blacklist_sites url_regex "/etc/squid/blacklist.txt"
> http_access deny blacklist_sites
>
> És az esetek 99% -ban működik is. (gondolom)
>
> a hivatkozott file -ban egymás alatt felva
Kedves Gyur!
> iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j
MASQUERADE
Sajnos ez sem működik.
> Egyébként squid-nek is...
Igen: tcp_outgoing_address; qmil: qmail-remote-outgoingip.diff.gz
Se a qmail-t, se a squid-et nem nagyon szeretném konfigurálgatni,
mert remélem
Üdv mindenki!
Van egy transparent proxy, remekül működik.
A szűrések is mennek(nagyrészt).
Valami rejtélyes oknál fogva néha nem szűr ki adott szavakat tartalmazó
url címeket.
PL: http://googletb.skype.com/skypelist-hu.xml ezt tiltja mert benne van
a "skype" a listában
de ezt az oldalt már nem:
Hi!
"Kónya Zoltán" írta 2008-12-15 14:10-kor:
> ez megvan, de sajnos ez nincs hatassal a problémára
> a "From:" mező (ahol az én userem van) a data sekcióban van! az igazi
> küldő MAIL FROM: (persze ez csak egy példa)
> a sender_access gondolom erre (MAIL-FROM) vonatkozik!? vagyis ez alapján
> ne
endomainem.tld REJECT You are not me
ez megvan, de sajnos ez nincs hatassal a problémára
a "From:" mező (ahol az én userem van) a data sekcióban van! az igazi
küldő MAIL FROM: (persze ez csak egy példa)
a sender_access gondolom erre (MAIL-FROM) vonatkozik!? vagyis ez alapján
nem tudom ellenőrizni!
Nalam elkapdossa oket a spamassassin.
nálam is, de a Junk mappába teszem és nem törlöm az assasin által spamnek
jelölt üziket!
és persze azt már beléjük rágtam, hogy mindig nézzék meg a spam mappát mielőtt
törölnék a tartalmát :) ekkor jön a baj, és a telefon
_
On Mon, December 15, 2008 12:46, Kónya Zoltán wrote:
> Sziasztok!
>
> Mostanában egyre több olyan üzenetet kapok, amiben a küldő és a címzett
> is ugyanaz!
> A felhasználókat eléggé idegesíti, hogy maguktól kapnak spames üzenetet!
> Persze meg is értem őket!
> Végigkövettem egy ilyen üzenetet a kül
Kónya Zoltán wrote:
> Mit tudnék ezekkel csinálni?
Nalam elkapdossa oket a spamassassin.
Kulonben miben mas, ha val...@valami.hu-s hamis email
cimrol kap spamet a user, mintha a sajat cimerol?
Igy legalabb tudja, hogy spam :)
Kulonben neked meg legalabb van alkalmad lenyomni nekik
az idevago
Sziasztok!
Mostanában egyre több olyan üzenetet kapok, amiben a küldő és a címzett
is ugyanaz!
A felhasználókat eléggé idegesíti, hogy maguktól kapnak spames üzenetet!
Persze meg is értem őket!
Végigkövettem egy ilyen üzenetet a küldő és a saját szerver között!
Sajnos a levelet az smtp kommunikáci
25 matches
Mail list logo
