Posts by bytesplit

Hi Nuxwin,

• the test install I am refering to was updated from ispcp 1.0.7 to imscp 1.1.0(?). I have noted down the tasks done and will reproduce the situation as the production system has not been migrated yet. On the test box I'm doing regular git updates (it's now at 1.1.19) so I thought the po_active should have come in the line of imscp upgrades. So I assume a fail in a imscp migration 1.1.x to 1.1.y. When was po_active introduced?
• I surely understand that it cannot reuse the ispcp dovecot user . But when it changed to dovecot_user, MySQL wouldn't accept it. I've now rechecked things and it was the iterate task which took a default select to table users (which in turn doesn't exist :)). So this is fine now that I've fixed the iterate task. DONE!

For the trouble:

• Yes that's why I have the LIKE %_mail%. To handle also "normal_mail,forward_mail". Something one of my resellers makes regular use of :). The case now seems to work with normal and forwards, alias and subdomains. Feel free to recheck though!
• The iterate query will sometime become relevant for iMSCP once Courier support get's pulled. I might be a dovecot nerd...Sorry!!!

Courier code has not seen much activity the last years. Dovecot now can use dbox instead of maildir to compress mailboxes and lower disk IO. Expunge autocleans Trash and Junk folders. Both these features make heavy use of doveadm. Then Full text search (short fts) is a very good plugin for high performant searches in roundcube using Solr. And I have more and more users relying heavily on the use of the webmail. Don't get me into the groupware (carddav/caldav) and cloud storage (ownCloud)... dovecot is future!

I've read about the courier support we have to keep and the not clear migration path. All true for years! Perhaps we can do the cut at 2.0... I'm waiting patiently Do we still have support for Lenny? RH 4? Apache 1.x?

Adding in the iterate query doesn't hurt much. Just some more bytes. And checking is as simple as doing a 'doveadm quota get -A'.

My big migration task is next weekend...

Sorry, by overhead I didn't mean the technical part. I was refering to the configuration burden of having to dynamically configure things like the mentioned dynamic IPs and such. On a root server I still think OpenVZ is more advanced or say experienced compared to Docker. The tools scope simply is different :).

Try running a (hidden) primary DNS inside imscp. Then customers can configure their domains easily through the webinterface. Many hosters provide secondary DNS for you.

I think this CLI script could be something helpful: Command line tools for i-mscp.

Sure, there aren't many hiccups in getting the product running inside docker. But I would not see this as a correct docker install. A correct docker install would launch automatically, grab the configuration from a central server and would finally start processes based on the configuration. This would in the end mean to happen dynamically e.g. load based.

When thinking about docker, I'd think about one central imscp panel server and many server hosting email and websites. A proxy director managing users to these different servers and reacting on traffic needs, launching service instances as website/mail traffic demands. For now this looks like a very long way to go still. The imscp services aren't split yet.

Don't get me wrong though, I welcome your efforts and future patches! For now the existing KVM, VZ (Proxmox in my case) tools are easier than (self hosted) cloud solutions (OpenStack and Amazon/Google/etc).

Hi there,

I've just started comparing my dovecot setup against the iMSCP test box. Yes, my production is still on ispcp and highly customized, so I'm really a bit slow in migration. But anyhow...

The SQL query is using prefetch, which is nice and what I want. Currently I still have the old way of domain, subdomain and aliasdomain queries. Checking through this, I've came across some problems...

The current query:

The minor problems:
- Compared to the github master I'm missing po_active = 'yes'. But beyond the SQL template I've not found this statement anywhere. It's not in my database (migrated from ispcp) either!
- When running imscp --reconfigure the user and password where overwritten, but it seems that the dovecot.data has not the migrated data from ispcp. There is dovecot_user which doesn't exist. I have ispcp_dovecot!

The trouble:
- the query fetches any email account! It fetches mail accounts and also forwards. So it could deliver to /var/mail/hostmaster! Ok, postfix would rewrite the forward before touching dovecot, but still seems strange.
- There is no iterate query for mail expunge or quota checking using doveadm.

I've added this:

and this:

Now you can again run 'doveadm quota get -A'. Perhaps nuxwin could incorporate the changes into the template?

I don't know to much about Docker yet...

But shouldn't things just work like on other VPS e.g. OpenVZ?

Do you want to run thousands of iMSCP instances in parallel? The shared filesystem will only save you some megabytes for system libs. I could also see splitting things up in services, but iMSCP is not yet as multiserver as the name implies...

- NAT can work just fine. Only check the FTP server settings.
- filesystem should go seperate in any way ( meaning /var/mail and /var/ww ), depends on your hoster
- Why disable DNS?
- Generally I would think of using puppet or chef to control imscp configuration in the docker way

Again, Docker seems to be to much overhead compared to the already existing VPSes... !?

Just a sidekick from me...

using mod_wsgi can be inefficient as it is loaded into every apache process (just as mod_php). So it might be okay if you run many different python-sites and no php. In iMSCP we more have this multihosting customer base. So it's kind off tricky to get a solution for those wanting PHP, then Python, then let's not forget about Ruby, Java/Groovy and so on.

I don't think that this is simple to accomplish with iMSCP. All later mentioned languages follow higher customized projects. For those virtual hosting like Docker/Git seems to be the way to go. Things like Heroku have way more expertise in this.

But for the simple cases of just running on or two sites with Python, check out these ideas:
- run nginx as front proxy with static files/php-fpm
- run uwsgi for python behind that nginx
- alt: run apache/wsgi for python also behind the nginx
- uwsgi could also be run with apache, but I'm not that big fan of apache anyway

As uwsgi is pretty much configured like fpm, it's perhaps not tooooo hard to write configuration wrappers for that ... Then I just read that uwsgi could also run Ruby apps. So well, might be a direction to go...

Hi,

nur mal ganz salopp... setze eine Virtualisierung auf! Dann geht Replizierung der ganzen Maschine wunderbar...

Z.B. könntest Du auf dem Backup-Server Proxmox installieren und dann den primären Server dort in eine virtuelle Maschine kopieren. Wenn dort dann alles läuft, den ersten Root-Server plätten und dort ebenfalls Proxmox installen.

Ceph oder DRBD. Failover-Szenarien, Backups, you name it... Alles dann ein VIELFACHES einfacher...

Mit einem simplen Backup-Server und Konfigs umherschieben hätte ich immer Bedenken, dass irgendwas fliegt. Ganz klassisch nur eine Konfig ist nicht ganz indentisch und wupps alles hinüber. Bei Virtualisierung kannst Du auch ne Test-Kopie für Versions-Updates machen und weiteres.

OpenVZ hat kaum Overhead da Container statt Virtualisierung. Nen Server mit CPU-Virtualisierung (neue Hardware?) brauchts auch nicht. Selbst wenns nur eine VM auf dem Host ist, Du bekommst maßig Flexibilität...

Dagegen sehe ich mir MySQL-Replikation, Dovecot dsync, ... alles einzeln? Buhuhuuu wenn da ein Software-Update oder gar System-Update kommt!?

Ja... meine 247 cents

Hallo Hans,

kannst Du bitte mal ne info.php machen und checken was in PHP konfiguriert wird? Nur falls nötig: Neue Datei irgendwas.php mit Inhalt:

Dein Include-Path kann nicht nur in /etc/php/php.ini gesetzt werden. Bei FPM z.B. auch in der pool-Datei. Weiterhin ist in den Apache-Config's ebenfalls die Möglichkeit für php_flag und php_value gegeben. Vielleicht magst Du /etc mal nach include_path durchsuchen? Google empfiehlt Dir hierzu ggf. das hier.

Viele Grüße

Just a side note:
if your customers complain about the greylisting delay, configure policyd-weight for conditional greylisting. That would turn on greylist only for unknown clients based on weight'ing.

I found this blog entry to be very useful: http://blog.waja.info/2007/08/03/conditional-greylisting/. (I'm not related to the author in any ways! It was just very useful for me :)) )

I'm using this setup for 2 years now, no delay still no spam. Layers are: policyd (configured for DNSBLs), amavis/spamassassin with several updated spamlists subscribed, greylisting only for very rare cases. Online shopping and forum setup are beautiful as all these new user approval mails show up instantly.

regards,
bytesplit

This looks quite like the munin graphs I have running on my server. Based on the screenshot, it is server wide statistics right?

What I could like, would be showing these graphs to customers filtered by their domains. But I guess this would be a real PITA.

Especially the number of dropped emails / e.g. SPAM would be great to show customers how much stuff is filtered away from their mailboxes...

hi,

although I guess many are requesting support for multi server-capabilities, this thread is pretty quiet.

I already played a bit with my install and I conclude that the solution should be easy to implement and thus understandable for the user.

Adding a server field to the domain tables would be the easiest part I could think off. This way each service needs to be configured to check only "his" customers, e.g. select from clients where server = myhostname. This could work out quite well for dovecot/postfix and probably also for apache too. Splitting login data db's could go wild when something is not reliably synced.

Thoughts:
Imapproxy can redirect dovecot logins
Incoming SMTP could go using DNS round robin and LMTP to dovecot, but would perhaps need a db for transport routing
For FTP, users would need to use their domain names (but with SSL only ftp.masterdomain works - no multisite!)

Given above db addition, I could setup some web servers, fewer mail servers and so on. I could think of them all accessing one central db. If the load is to much, I could setup replication slaves on the different servers.

DNS could also go on the master server and replicate to the others as slaves. If wanted, one could also set it up as a hidden primary. I think this is also not that big of a trick.

But to make this all useful, we would need a conversion feature, something to move an account to a different box. And that's the tricky thing for me. Should the master server run SSH'ed rsync using keys to copy stuff around the servers? Can we make sure that it all copied successfully? When do we shut one down and start the other? Then how about quota and traffic counters... they can hardly be copied to another server!?

In the end, step 1 seems nearly done for me. Customers only accept one panel and we keep using that, roundcube can use imapproxy. WebFTP could probably also select the server based on the customer login. The big step is really this customer migration/move functionality...