Posts by biologist

    I'm using imscp's provided plugins for spamassassin (sa) as well as opendkim. In config.php you stated, that dkim should not be activated if opendkim-plugin is already active. Why? Currently, opendkim signs messages or checks, if a signature is valid - but usually nothing happens if a signature is invalid. What about letting sa to perform dkim-checks as well in order to (potentially) increase spam-value?
    Or did I get something wrong? :-)


    Thanks in advance.

    I packed the client/server into a file and attached it. Source: don't know - found anywhere in the web round about a decade ago. It's nothing fancy - just straight forward :-)


    Ok, let me outline this a little bit:
    Guess there's a domain "domain.de" which I want to provide a dyndns-service for. For example dynip.domain.de. Now domain.de was set up in imscp but without telling imscp anything about the subdomain dynip. So the domain/zonefile is under imscp's control.


    On client side, there's a pretty small perl-script running (ddnsclient), that sends messages to the server using sslcat. On server-side, there's stunnel, that calls "dns-server.pl". There's a user file "hosts", that looks a bit like smbpasswd-file - all valid clients/users a listed there with a crypted pwd following. So after checking if the client sent a correct user/password-combination, "dnsupdate.pl" is called. It uses nsupdate to "inject" the client-ip into the zone managed by imscp/named. As I described previously: this injection leads to creation of domain.de.db.jnl. This in turn is so to say critical, because it makes bind ignoring any changes in the zonefile unless jnl exists.


    So everything is perl-based so far. But in the end I don't care if it's perl or php :-)
    I'd really appreciate some further information on what exactly has to be triggered.

    Files

    • ddns.zip

      (3.93 kB, downloaded 7 times, last: )

    Hi Nuxwin,


    there's an dyndns-service running on my server. Using a secured connection, a zone-update is done by using bind's nsupdate - it's so to say an injection into the zone. Now the thing is that <domainname>.jnl is created after doing such an injection. Critical about this file is that the corresponding zone-file can be changed but the changes won't be propagated unless .jnl exists. So it's necessary to delete .jnl on order to allow propagation. So I'm thinking about on how to design a named listener to address this problem.


    Possible solutions
    1) A named-listener that looks up and stores the ip that was previously injected, deletes .jnl und re-injects the IP finally.


    2) Creating a custom-dns-entry in imscp. Updates won't be propagated through nsupdate anymore - instead I'd change the IP-address of the given entry directly in imscp's database. But for me the question is: what do I havo to call to tell imscp, that the zone needs an update?


    I'd prefer #2 because #1 is pretty dirty.
    But maybe you've got other ideas/hints/whatever.


    Please note this ddns-service is completely custom - it's nothing an user can activate/deactivate in any way.

    Currently, I'm running two servers, as my old one will be migrated to new one (almost finished). I set up everything so far and it's running fine. Now the point is, my new server will use the IPs from my old server but is currently (temporarily) set up with other IPs (v4/v6.) I'm aware, that I'm responsible to change the network-configuration of my linux machine. Anyway: imscp has to re-generate all configs again. In order to prepare this step, I tried to add the IP (/27-network) from my old-server to the new one via imscp's gui, but ran into " Modules::ServerIP::add: Can't call method "isEmpty" on an undefined value at /var/www/imscp/engine/PerlLib/iMSCP/EventManager.pm line 231."
    Please note: the IP from my old server is not yet part of my network-configuration - so imscp cannot determine it automatically or take notice of it in any way. However, I tried to add it in manual-mode.


    Don't know if it's working as intended (and I did something wrong) or this is a bug. Maybe the preferred way is to call
    /var/www/imscp/engine/setup/imscp-reconfigure -dr primary_ip when the network-configuration was changed to the new (so to old) ip.



    Version: Git master (a few days old)