Posts by biologist

Just as hint: spamassassin needs to be trained (at least basically) to perform well. It needs tons of spam to render its spam-propability-scoring reliable.
In that order I advised my clients to put all their spam into a junk-directory. Every 2hrs (cronjob) spamassassin gets trained via sa-learn by scanning all these junk-folders recursively. For sure I also implemented a ham-folder for false-positives.

I don't know how exactly you implemented the plugin (didn't have a look at it as I'm using my own integration) but if you don't use sa-learn so far, use it because it's worth it However, if it's already activated forget my post

Ist meiner Meinung nach der falsche Ansatz - zumindest es SO kurz zu setzen. Das Benutzer sich beschweren, liegt u.a. auch daran, dass sie technisch einfach keine Ahnung haben, warum es zu einem Delay kommen kann. Das, was du eigentlich suchst, ist delay_warning_time. Das ist nämlich die Zeit, nach der der Absender informiert wird, dass seine Mail noch in der Q ist.

Edit: Ich sehe gerade, dass du mit dem Parameter ja auch schon "gespielt" hattest

Postfix anschließend neu gestartet?

Also so ganz habe ich es noch nicht verstanden, wie du die Sachen übernehmen willst. Aber wenn du die Kunden manuell auf dem neuen System manuell anlegst, dann kannst du die Datenbankeinträge natürlich nicht 1:1 übernehmen, weil die DB-Referenzen nicht mehr stimmen. Also wenn die Anzahl überschaubar ist, mach doch Folgendes:

1) Lege die Konten manuell auf dem neuen Server an.
2) Lege Mail und FTP-Konten ebenfalls an - die Passwörter dazu findest du in der alten DB im Klartext
3) Übertrage Mails und Webcontent
4) Passe die Rechte an

Funktioniert gut, ist aber halt ggf viel Arbeit und auch fehleranfällig, weil man gerne mal was vergisst.

Andere Möglichkeit: lösche den Kram, den du nicht mehr brauchst schon auf dem alten Server und übernehme die Datenbank komplett.

Im Endeffekt hat das ja mit imscp nichts zu tun - es richtet dir die Sachen ja nur ein. Entsprechende "Feinjustierungen" kannst du in Templates ja jederzeit vornehmen. Der einzige Bestandteil von imscp, der sich durch ein 64Bit-System ändert, ist der Daemon. Der ist halt in C geschrieben und muss entsprechend im passenden System kompiliert werden. Aber ich gehe mal davon aus, dass du den nicht meinst

Seems as I should go a little more into detail....

1) It starts with the partition-layout - said this it's also highly depended on the size of your harddisks. Some backup-strategies rely on the generation of TARs, which are stored at least temporarily on backuped system. In this case, you have to make sure, these backups are stored on a seperate partition, as otherwise e.g. the root-partition could be affected because it's running out of space. Not only because of the backup-files that are maybe growing by the time... What if the generated TARs are saved and cannot get transferred to the destination? And whats the reason for this? Backup-capacity reached? Firewall? Backup-system down? These are just some reasons and most of them require manual interaction. When you implemented this stuff by yourself, you know how to fix that. You are familiar with that! If you just rely on imscp, like many users without doubts, you likely do not. Result: additional community-questions.

2) The strategy on how to backup a system depends on the data you host and especially the amount. In my opinion it takes really big efforts to abstract this. Why do you want imscp to do that? It's your job! You have to know how often and in which way data has to be backuped. And while doing this: you don't have to start from scratch. There are tons of tools freely available. And in the end, there's still rsync - use it!

3) Say there's a backup-feature implemented - there are tons of ways to backup-data. I guess new requests will drop in on and on for new ways to be implemented. It's just additional work that shifts imscp's focus.

I'm not a developer of this project, but I'm simply astonished about all these feature requests. There are questions on and on about things, that should be basic stuff for an administrator. I'm sure a lot of imscp-users have absolutely no clue of how much stuff already got automated. Really! I can tell you: I do, because I'm running imscp on Gentoo and have to perform all of these install-steps manually. I have to touch almost every config to get it running. Yes, this absolutely my problem and I don't recommend it. But I'm really wondering about administrators that profit from a fully automated install-task (using Ubuntu/Debian) and still are too lazy to do basic tasks on their own. Running a server means to accept responsibility!

Do you use dovecot? I also discovered slight changes in the naming, but in the end, all mails were accessible on the new server. Just give it a test.

Quote from Shinzan

Alternatively even a bash script (perhaps I should research this) to itterate though /var/www/virtual/../backup and then upload all files that have term SQL in it to the ftp of my choice.

So why don't you just write such a script to transfer/backup the data anywhere else!?
Just waiting for the one that needs imscp-assistance for the toilet...

Quote from redcloud

Great! Thanks! Do you know also if there's a planned enhancement for backup procedure?

Shouldn't that be your part to plan and perform such an important task? How do you expect imscp to do that? Save the backup anywhere else on the same hdd and if the hdd crashes, it's also gone? It's very very simple to backup mails. And the best: all you need, beside of a second storage anywhere else, is rsync!

In my opinion, it's not sufficient to backup just parts of a system. So get up and get familiar with rsync, duplicity and whatever - it's kinda simple.

Geht es um eine Webpräsenz von einem Kunden und von dem wurde plötzlich gespammt?
Wenn ja: schau dir mal die Logs vom FTP an. Ich hatte das vor mehreren Monaten auch, dass von mehreren Kunden die Zugangsdaten ausgespät wurden. Dadurch wurden php-Files in den jeweiligen Webspace geladen und dann ausgeführt. Am Ende wurden diese Files wieder gelöscht.