Recent content by mr-wolf

Before it would remove all the TXT-records. The only way to remove one now is by giving its value... A DKIM-record contains special characters and it's quite hard to get the proper value in a bash-variable to get it deleted. How it worked wasn't ambiguous at all. It doesn't/didn't do anything...

I have a script running some 4 years which removes a TXT-record and then adds a new one. It used the syntax: /usr/local/psa/bin/dns --del ${DOMAIN} -txt '' -domain ${SUBDOMAIN} Notice the double single quotes. I never gave it the TXT-value, but still the record was removed. I never tested if...

I though it would fix all ownerships and permissions of files in /var/www/vhosts/<site>/ -y means yes to all -v means verbose... Apperently only a limited subset.... You need to do it manually!!

If you login as root and invoke this command It should fix all permissions of your site. It would also fix the git_known_hosts owner. (edit: No, it doesn't) You can also do it by yourself with the chown command.

I can only tell you things for which you give info. I also don't know what you know or don't know, I can only presume and give you as much info. You need to be the judge of what is applicable to your situation. You don't give examples which makes it clear for me what the user name and...

/usr/local/psa/admin/sbin/modules/git/git_ssh: line 49: /var/www/vhosts/[site-url]/.ssh/git_known_hosts: Permission denied You do NOT have access to the file git_known_hosts You are running it with a user that doesn't have write permissions to that file and you have to solve that first. I...

Like the message says: run This will remove the key of bitbucket.org out of the local file you have on your server (/var/www/vhosts/[site-url]/.ssh/git_known_hosts) It will then have nothing to compare with Then start it again and give "yes" to accept the new public key When you first...

@moswak No comment?

I've read your posts again considering the new options. I can't see what has changed for you regarding your use case. The only thing you now need to do is opt voor option #2 whenever you migrate a domain to another mailserver. The 3rd option is a bit unnecessary IMHO. I remove the mail...

OK.... Everything above written by me was written without the knowledge of this new option. As I see it, the 3rd option should be considered as something new. Instead of "unconfigured", you should now set it to "Disabled for incoming mail" When set for "disabled for incoming mail" it will send...

Local or remote DNS has nothing to do with what I'm bringing up. If a server has active mail for that domain, it will not check DNS. It has always been that way and not only for Plesk. I was merely bringing it to your intention. An active mailserver without MX-records pointing to it can...

Thanks a lot for that info. Like I said it's the main DNS-server (I'm not doing DNS on the different Plesks beside the Letsencrypt DNS for the wildcards). Unlike all others, it's a VPS, so I should be able to recover with a snapshot. It has a pivotal role, so I really can't be messing with it...

I've always preferred Debian/Ubuntu, but when I decided a distro for my authoritative DNS-server, I chose for CentOS. I wish I didn't. When I need a new Plesk I configure a complete new machine and migrate all the domains to it. Never dared to do a dist-upgrade. Only recently I heard about this...

In an environment as a provider this is certainly a misconfiguration... If 2 customers are on the same server, the one with the remote MX will not receive any mails from that other client on the same webserver. Any mail he sents to a domain with local mail will be kept on the Plesk server.

IMHO plesk is just an interface shell to manage the various open source programs apache, nginx, postfix, dovecot, bind, mysql and others. It does so by merely manipulating their configuration files. For Plesk these programs dictate how the configurations should be. Plesk shouldn't filter...