Unrelated subdomain put into error state when updating custom DNS

    Running on 1.1.0-rc4.4


    I've been playing with the custom DNS system, trying to get a mailing list working, and managed to put the system into an unsupported state


    I did not play with any "subdomain" features... however, after adding MX and A and CNAME entries, the one subdoman I had got put into an error state, and all the other custom DNS entries became unavailable to edit.


    Looking at the subdoman table, the status of this subdomain is


    Code
    1. iMSCP::Debug::__ANON__: Use of uninitialized value in concatenation (.) or string at /var/www/imscp/engine/PerlLib/Modules/Subdomain.pm line 191, <$fh> line 732.Servers::named::bind::addSub: Unable to install zone file domain.tld.db


    This occurred after a manual database change of an MX record from "domain.tld" to "lists.domain.tld" (because the GUI doesnt support that, and I need that functionality - Nuxwin is on a separate thread about this) and then adding new custom DNS record to have the domain.db file regenerated.


    Let me know if I can be of more help.
    [hr]
    Ok - this has got bigger than a simple "oops"


    When the domain became unstable I deleted it, and tried to recreate it. No dice. It started ok, but then as I tried to add different things, it too became unstable. I deleted that domain as well.


    Then I got notice that 1.1.0-rc4.5 was released. I figured I would install that to see if that solved the problems.


    nope... installer runs, and tries to rebuild the sites and ends up throwing a pile of errors



    Now, apache isnt running, which makes finding the errors in the db a lot harder :dodgy:


    The last domain in the 'domains' table has an ID of 7 - so I'm not sure where the vu2010 reference is from. It can only be from an incomplete deletion of the domain earlier today.


    I also cant go back to 1.1.0-rc4.4 - it looks like the same errors are being thrown (which leads me to believe it's the database being in a corrupted state)


    Still - it would be nice rather than to crash the entire system like this, if the rebuild process just disabled the domain in question, rather than everything :angel:


    It looks like the perl modules are trying to build $self in Domain.pm and Alias.pm - but there's data coming from all over to build that object.


    I've dumped the entire imscp database to a text file, and searched for vu2010 - and it doesnt exist. The only references to '10' in the database (I'm assuming you'll build a vu2010 dynamically) seem to be key ids, not domain ids...


    I dont see a domain in the /etc/apache2/imscp folder .. or the /etc/apache2/sites-available folder but running an apache2ctl -t definitely shows that it's picking up a config for the domain that was deleted, and when I search the filesystem for references to the deleted domain, there are a ton of them there, log files, bind files, error logs from apache... fcgi folders...


    My first reactopn was that if you can identify what need to be cleaned on the database, I can manually clean it - but this looks like it goes a lot deeper than database cleanup.


    I've attached a list of files on the file system that remained after the domain was deleted.


    I'm going to fix apache so that it comes up - but there's something that needs to be corrected in the deletion process...

    Files

    • bad_refs.txt

      (4.92 kB, downloaded 45 times, last: )

    Edited once, last by NexusAdmin ().


    Hello;


    This is what happens when we start to change i-MSCP template files or the code without knowing what we are doing ...


    If you need online support, send me your teamviewer IDS.


    Thanks you for using i-MSCP.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support


    :blush: This is what happens when we try to regain lost functionality :blush:


    Cleaning the file system of the files I attached fixed the issue - which to me points back to an issue with the domain delete process. If, as the admin, I say "delete domain.tld" and check the check box indicating i'm ok with it doing a massive update, then I would expect all the related entities to be gone.


    If I log in as the admin I'm trying to use the biggest hammer I can use. I *want* to override all the immutables, and read-only, and hidden files. Simply put there should be no remnants *anywhere* if the admin deletes a domain.


    As a developer with over 30 years of professional development under my belt, I understand that nothing is foolproof, as fools are ingenious and do unexpected things. Perhaps not so much early in my career, but lately, there's been a great emphasis on "dont let people screw themselves up" because users of systems, do not expect anything they do to leave the system in an unusable state. They expect things to be transactional in nature - it either all worked - or none of it was applied.


    Anyways ... I still think there's an issue inside the Domain Delete process that needs to be looked into. Please see the list of files that were left on the file system after the domain was deleted. Something in that list created the errors above, even though there was no reference in the database.


    So perhaps there are two problems

    • Domain Deletion is not deleting everything it should
    • Setup/reprocessing is looking at the file system rather than the database


    I am happy to tell you that after cleaning the file system 1.1.0-rc4.5 is running on the server now. :D


    Thank you for your offer :D

    I'll check and fix if needed.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    Should be fixed in last Git Master.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support