Onderwerp: Zonefile splitsen

Oorspronkelijk geplaatst door Paul Z.

Is het niet mogelijk om de lijst die al in de database staat te gebruiken met een DNS die ook met een database werkt.
PowerDNS is geloof ik zo'n pakket wat z'n data uit een DB kan trekken...

Of is dit geen optie?

Wij (ik) zullen ons eerst moeten verdiepen in PowerDNS om te kijken of dit een optie is ja of nee. Wellicht dat we dit naast ons huidige systeem kunnen draaien voor alleen de blacklist. In ieder geval bedankt voor je bijdrage. Ik zal er is in duiken.

___

Oorspronkelijk geplaatst door groenleer

Wat ik bedoel is wat Paul Z. hier boven ook al aangeeft.
Met BIND kan het ook.
http://mysql-bind.sourceforge.net/


p.s. de reden waarom ik hier MySQL+BIND aan haal is omdat DA zelf gebruik maakt van BIND, en TS het zelf al over MySQL heeft. Het is waarschijnlijk een kleine aanpassing voor hem om de tabel met verbannen ip's om te zetten naar een DNS tabel.

Bedankt! We (ik) zullen eens kijken of het makkelijk is om die tabel met IP's om te zetten naar een DNS tabel. Dit zou inderdaad een mooie optie zijn om te gebruiken voor de blacklist. Dan hoeft er ook geen file meer gegeneerd te worden...

___

Oorspronkelijk geplaatst door ivs

Moet je het probleem niet gewoon bij de bron aanpakken? dus zorgen dat het php script sneller is.

Wat doet dat php script trouwens want een lijstje outputten is nou niet echt lastig ook al is die lijst heel lang.

Daarnaast kun je het php script ook aanpassen zodat het via de commandline gestart kan worden dan heb je geen last van time-outs.

Het probleem bij de bron aanpakken hebben we reeds geprobeerd.. Er zijn enkele recodes geweest.. Het lijstje waar jij over spreekt is een lijst met zo'n 100.000 entry's (daarna cleanen we de database nu omdat die anders uit 't geheugen loopt).. We starten het script al via de command-line en we lopen ook neit tegen timeouts aan maar tegen 't mem limit van PHP. Wat we nu kunstmatig hoog gezet hebben in het script.

Ons script is (zoals eerder gezegt) gepost op: http://www.wmcity.nl/forum_topic.php?id=630662 Wanneer jij denkt een verbetering te zien is die natuurlijk welkom!

Oorspronkelijk geplaatst door SomeOne

Ons script is (zoals eerder gezegt) gepost op: http://www.wmcity.nl/forum_topic.php?id=630662 Wanneer jij denkt een verbetering te zien is die natuurlijk welkom!

Ik heb je een werkende verbetering gegeven!

Het probleem bij de bron aanpakken hebben we reeds geprobeerd.. Er zijn enkele recodes geweest.. Het lijstje waar jij over spreekt is een lijst met zo'n 100.000 entry's (daarna cleanen we de database nu omdat die anders uit 't geheugen loopt).. We starten het script al via de command-line en we lopen ook neit tegen timeouts aan maar tegen 't mem limit van PHP. Wat we nu kunstmatig hoog gezet hebben in het script.

Volgens mij zijn er tal van mogelijkheden een paar suggesties:

-kijk wat het geheugen gebruik veroorzaakt 100.000 entry's is niet zoveel.
-schrijf de resultaten tussentijds weg
-hak het proces in stucjes (dus meerdere keren achter elkaar php opstarten) en dan achteraf de losse files aan elkaar plakken.
- maak een slim script wat alleen de aanpassingen doet dus niet steeds alle entries aflopen maar alleen de wijzigingen

Oorspronkelijk geplaatst door ivs

Moet je het probleem niet gewoon bij de bron aanpakken? dus zorgen dat het php script sneller is.

Wat doet dat php script trouwens want een lijstje outputten is nou niet echt lastig ook al is die lijst heel lang.

Daarnaast kun je het php script ook aanpassen zodat het via de commandline gestart kan worden dan heb je geen last van time-outs.

Het getoonde script achter de link ( in TS zijn openingstopic ) is al een script wat gerunt word @ console met een cron

Er is dus geen interactie tav. timeouts of whatsoever , et draait, alleen et used zoveel resources dat er dus gezocht word naar die splitsing/andere methodieken.

enige wat wel aanwezig is op een http-interface is de add-form naar de Db zelf, dan word dat snachts per cron verwerkt in een zonefile die dan weer op zen plek gezet word en de zone opnieuw inleest....

@ Mikey

ga et gelijk bekijken ...

Oorspronkelijk geplaatst door ivs

Volgens mij zijn er tal van mogelijkheden een paar suggesties:

-kijk wat het geheugen gebruik veroorzaakt 100.000 entry's is niet zoveel.
-schrijf de resultaten tussentijds weg
-hak het proces in stucjes (dus meerdere keren achter elkaar php opstarten) en dan achteraf de losse files aan elkaar plakken.
- maak een slim script wat alleen de aanpassingen doet dus niet steeds alle entries aflopen maar alleen de wijzigingen

Hebben er al veel aan gesleuteld, en er was ooit eens iemand die een php-class had gemaakt voor het afhandelen van dns-zone-files, ( PEAR::File_DNS )

echter heeft die class al heel lang :

1 - geen update meer gekregen
2 - zijn de huidige functionaliteiten nog niet dusdanig dat die voor deze opzet gebruik kon worden.
3 - creator aangeschreven maar et enige wat ik terug krijg is 'static'

en over het re-coden/optimizen van et script/set scripts word constant nagedacht, maar vragen wil wel es helpen om bepaalde dingen te doorbreken in plaats van altijd het wiel zelf maar opnieuw uit te vinden ....
vandaar ook de vraagstelling

al met al een hoop reacties gehad tot nu toe waardoor onze (mogenlijke) oplossing gerealiseerd kan worden lijkt me ...

kwestie is nu nog van 'wat is wijsheid' inzake de te kiezen oplossing...

- mysql-bind oplossing
Tricky op een RPM-based setup (CentOS 5).. requires recompile, en hoe gaat dat dan met je volgende updates van bind ...et feest weer overnieuw ?

- php recoden
Ja kan, maar geeft alleen nu een remedie, ik verwacht ( zoals aangegeven) een veel grotere DB, nu groeit de Db per dag met ca 500 ip's ( poster loopt bepaalde bronnen af om ip's op te snuffelen/adden)

- Include
Limitaties niet echt duidelijk aangegeven, dus kwestie van try

Misschien heb ik het helemaal verkeerd begrepen (zal ongetwijfeld, 't is nog vroeg..) maar wil je niet gewoon een firewall al dit verkeer laten blokkeren? Het gaat immers om verbannen ip's..