Actually I already tried iReadmail 0.6.1 on Ubuntu 10.04 , but got message that it is unsupported . So went with Debian . Patching was successfull. Just before creation of squashfs some strange errors occured. I think , it is the problem wuth TKLPatch on debain . Waiting for Liraz 's and Alon 's reply ....
If you are using that version and problems persist be good to let them know of the potential bug and let them help you figure it out. Then everyone's a winner! :)
Seems like these guys put some effort into solving a common problem (mail) with a lightweight combination of excellent open source components. A TurnKey equivalent would likely be a great idea. I can understand Basil's reluctance to step in though. I suspect he doesn't want to take credit for just running an iRedMail script.
If that's the case, I'd like to clarify one thing - it still very useful to say I've tested this combination and it works.
As you can see from the docs the installation process is interactive so we can't just run iRedMail.sh script in a TKLPatch's conf. Unfortunately, for a TKLPatch to be easily converted into a TurnKey appliance it shouldn't require user interaction. That rules out just running the iRedmail.sh script without modification. But that doesn't mean we can't leverage iRedMail. We just have to be more clever.
I've taken a closer look at how iRedMail is implemented and it is a behemoth shell script program that codifies a great deal of mail server integration knowledge. It's impressive work!
The good news is that this is a very well written shell script that doesn't repeat itself. All the dialog code is in one place, and it's called from a single function (check_env() in conf/core) which is itself called from the main iRedMail.sh script. The output from the interactive configuration process is a configuration file. We can take this file, and with minor modifications short-circuit check_env to use it directly without any user interaction.
The result: a TKLPatch containing an iRedMail.sh script that can be run non-interactively, which can in turn be used to create a TurnKey iRedMail appliance.
From what has been said above, it sounds like you can prefill the config file and pipe a 'Y' to the script. Then no user interaction should be required, and no modification to the script.
I was looking at this appliance and want to finish it so that it makes its in the final TKL lucid release. I'm right now checking the options in the installation, and testing it with ldap backend. I did it first to check the iRedAdmin software. It looks pretty nice, but I don't like the fact that the opensource edition lacks of a lot of features from the payed version. It makes me feel I'm running an uncomplete program. Said that, do you guys think this appliance should go with the mysql backend and using postfix-admin? I'm going to check that one right away.
Also, if ldap backend is the way to go, would example.com be a good root for the tree? I did use that and got a config file like the one previously posted, but this subject regarding ldap always make me think on how to setup an appliance generic enough. I think we can end up with something more generic, so ideas are welcome, if you want to, post them in the ldap tklpatch post.
Stripped down community version: Only the iRedAdmin interface is stripped down and it's just a configuration UI. The actual functionality is provided by the other open source components and it's all there. As you suggest we don't have to settle for iRedAdmin and can provide a full configuration UI to postfix via the Webmin module. I haven't evaluated iRedAdmin in detail yet but if we come to the conclusion that the community version doesn't add anything useful on top of what we can accomplish with Webmin (e.g., postfix configuration) we could just remove it. In that case we probably shouldn't call it iRedMail though.
Inithook configuration screens: Regarding configuration tweaks, Alon is working on supporting configuration dialogs in inithooks so the default ldap root could be example.com. This will apply in live CD/demo mode. When the user boots for the first time after deployment we can ask him for the real root domain name and make the proper reconfiguration. I'll ask Alon to document how inithooks configuration dialogs work as soon as they're stable.
Is another topic that makes me think. I'm setting mail.localdomain for this one, and I'll check the implications of changing that later to a real fqdm (check that nothing brokes). This part I think would be important to add to the "firstboot configuration wizard". That would help things like this to get properly setup when first installing the appliance.
For the benefit of anyone reading this thread, Adrian took a stab at resolving some of the issues (e.g., running iRedMail non-interactively) and posted a more complete patch here.
And I agree that it would fill a niche in the lineup nicely. Unfortunately we're currently running flat out to pretty much stay in the same place, so if no one from the community picks it up as a project (i.e. develops TKLDev build code) then it is unlikely it will make it into the v13.1 release (although you never know)... OTOH if someone develops the build code then the chances of including it are pretty good!
If that's something that you think you might be able to help with, let me know (maybe start a new thread) and I'm happy to help as much as I can.
Did this project get stuck in the transistition to TKLDev? Are you still looking for a sponser?
I started looking for a TurnKey GNU/Linux solution for handling mail when my homebrew server started receiving a lot of Phishing messages. At first I worried I had been hacked, but that seems not to be the case. I just need better spam filtering. iRedMail seems to have many of the features I'm looking for. If no one else is working on this currently, I could take a stab at rolling a TKLDev version.
Information is free, knowledge is acquired, but wisdom is earned.
Unfortunately Axigen is "proprietary license" so that's not an option. We only provide appliances containing open source software. Although we do have intention to provide a Docker host appliance at some point. So once that's available, it should be a pretty easy install.
Although you are right, it'd be great to have a mail server appliance. Unfortunately, we have a lot going on behind the scenes. So to get it added to the library any time soon, a community member will need to step up and do the work.
how long to publish
I just wonder how long do need to finish the iRedMail project?
Already created the patch
I have already created the patch , Have some problem with TKLpatch tool on Debian. So waiting for Liraz and Alon to look into it.
Ubuntu 10.04 perfect support
Now iRedMail 0.6.1 is perfect in Unbutn 10.04, can you first publish Ubuntu 10.04?
.
.
Actually I already tried
Actually I already tried iReadmail 0.6.1 on Ubuntu 10.04 , but got message that it is unsupported . So went with Debian . Patching was successfull. Just before creation of squashfs some strange errors occured. I think , it is the problem wuth TKLPatch on debain . Waiting for Liraz 's and Alon 's reply ....
Hey Basil have you checked out their forum?
Because I just had a quick look and the first thing I saw was: "iRedMail-0.6.1 released, with Ubuntu 10.04 LTS support. 2010-08-16" In the thread it states: "Supports Ubuntu 10.04 LTS. 10.04 is recommended version if you want to deploy iRedMail on Ubuntu."
If you are using that version and problems persist be good to let them know of the potential bug and let them help you figure it out. Then everyone's a winner! :)
let me try once more .
let me try once more .
I was wrong
I was wrong .new version of iRedmail is supported on lucid. Earlier it was my mistake
when i did
it is ok
bash iRedMail.sh or bash
or
bash iRedMail-0.6.1/iRedMail.shwould also ok.
another question, whether intergrate webmin and virtualadmin to iRedmail project ？
iRedMail looks very interesting
If that's the case, I'd like to clarify one thing - it still very useful to say I've tested this combination and it works.
Thoughts on porting iRedMail to TurnKey
http://code.google.com/p/iredmail/wiki/Installation_on_Ubuntu
As you can see from the docs the installation process is interactive so we can't just run iRedMail.sh script in a TKLPatch's conf. Unfortunately, for a TKLPatch to be easily converted into a TurnKey appliance it shouldn't require user interaction. That rules out just running the iRedmail.sh script without modification. But that doesn't mean we can't leverage iRedMail. We just have to be more clever.
I've taken a closer look at how iRedMail is implemented and it is a behemoth shell script program that codifies a great deal of mail server integration knowledge. It's impressive work!
The good news is that this is a very well written shell script that doesn't repeat itself. All the dialog code is in one place, and it's called from a single function (check_env() in conf/core) which is itself called from the main iRedMail.sh script. The output from the interactive configuration process is a configuration file. We can take this file, and with minor modifications short-circuit check_env to use it directly without any user interaction.
The result: a TKLPatch containing an iRedMail.sh script that can be run non-interactively, which can in turn be used to create a TurnKey iRedMail appliance.
What I mean is , I edited the
What I mean is , I edited the dialog scripts in iRedmail to avoid interaction with user ,and assigned the required value to variables.
Have you tried what Liraz & Zhang discussed above?
From what has been said above, it sounds like you can prefill the config file and pipe a 'Y' to the script. Then no user interaction should be required, and no modification to the script.
But there are some check
But there are some check boxes also in the dialogs , what about them ??
maybe you need consider
maybe you need consider provide two iso, one is for ldap, the other is for ldap
the below is ldap config files
##################
iRedMail-0.6.1# cat config
export VMAIL_USER_HOME_DIR='/var/vmail'
export STORAGE_BASE_DIR='/var/vmail'
export SIEVE_DIR='/var/vmail/sieve'
export BACKEND='OpenLDAP'
export dn2dnsname="example.com"
export LDAP_SUFFIX="dc=example,dc=com"
export LDAP_SUFFIX_MAJOR="example"
export LDAP_BINDDN="cn=vmail,dc=example,dc=com"
export LDAP_ADMIN_DN="cn=vmailadmin,dc=example,dc=com"
export LDAP_ROOTDN="cn=Manager,dc=example,dc=com"
export LDAP_BASEDN_NAME="domains"
export LDAP_BASEDN="o=domains,dc=example,dc=com"
export LDAP_ADMIN_BASEDN="o=domainAdmins,dc=example,dc=com"
export LDAP_ROOTPW='iredmail'
export USE_IREDAPD='YES'
export MYSQL_ROOT_PASSWD='iredmail'
export FIRST_DOMAIN='example.com'
export DOMAIN_ADMIN_NAME='postmaster'
export SITE_ADMIN_NAME='postmaster@example.com'
export DOMAIN_ADMIN_PASSWD_PLAIN='iredmail'
export DOMAIN_ADMIN_PASSWD='iredmail'
export SITE_ADMIN_PASSWD='iredmail'
export FIRST_USER='www'
export FIRST_USER_PASSWD='iredmail'
export MAIL_ALIAS_ROOT='www@example.com'
export ENABLE_DOVECOT="YES"
export DOVECOT_PROTOCOLS=' pop3 pop3s imap imaps'
export ENABLE_DOVECOT_SSL="YES"
export ENABLE_SPF='YES'
export ENABLE_DKIM='YES'
export USE_IREDADMIN='YES'
export USE_WEBMAIL='YES'
export USE_RCM='YES'
export REQUIRE_PHP='YES'
export USE_PHPLDAPADMIN='YES'
export REQUIRE_PHP='YES'
export USE_PHPMYADMIN='YES'
export REQUIRE_PHP='YES'
export USE_AWSTATS='YES'
export DEFAULT_LANG='en_US'
#EOF
I'll step in to finish this appliance
I was looking at this appliance and want to finish it so that it makes its in the final TKL lucid release. I'm right now checking the options in the installation, and testing it with ldap backend. I did it first to check the iRedAdmin software. It looks pretty nice, but I don't like the fact that the opensource edition lacks of a lot of features from the payed version. It makes me feel I'm running an uncomplete program. Said that, do you guys think this appliance should go with the mysql backend and using postfix-admin? I'm going to check that one right away.
Also, if ldap backend is the way to go, would example.com be a good root for the tree? I did use that and got a config file like the one previously posted, but this subject regarding ldap always make me think on how to setup an appliance generic enough. I think we can end up with something more generic, so ideas are welcome, if you want to, post them in the ldap tklpatch post.
Add-ons to iRedMail + configuration tweaks on firstboot
Stripped down community version: Only the iRedAdmin interface is stripped down and it's just a configuration UI. The actual functionality is provided by the other open source components and it's all there. As you suggest we don't have to settle for iRedAdmin and can provide a full configuration UI to postfix via the Webmin module. I haven't evaluated iRedAdmin in detail yet but if we come to the conclusion that the community version doesn't add anything useful on top of what we can accomplish with Webmin (e.g., postfix configuration) we could just remove it. In that case we probably shouldn't call it iRedMail though.
Inithook configuration screens: Regarding configuration tweaks, Alon is working on supporting configuration dialogs in inithooks so the default ldap root could be example.com. This will apply in live CD/demo mode. When the user boots for the first time after deployment we can ask him for the real root domain name and make the proper reconfiguration. I'll ask Alon to document how inithooks configuration dialogs work as soon as they're stable.
New inithooks documentation
I'll be brief: It's here.
FQDN for this kind of appliances
Is another topic that makes me think. I'm setting mail.localdomain for this one, and I'll check the implications of changing that later to a real fqdm (check that nothing brokes). This part I think would be important to add to the "firstboot configuration wizard". That would help things like this to get properly setup when first installing the appliance.
Comments welcome!
Adrian iRedMail patch
For the benefit of anyone reading this thread, Adrian took a stab at resolving some of the issues (e.g., running iRedMail non-interactively) and posted a more complete patch here.
It'd be great to have in the library!
And I agree that it would fill a niche in the lineup nicely. Unfortunately we're currently running flat out to pretty much stay in the same place, so if no one from the community picks it up as a project (i.e. develops TKLDev build code) then it is unlikely it will make it into the v13.1 release (although you never know)... OTOH if someone develops the build code then the chances of including it are pretty good!
If that's something that you think you might be able to help with, let me know (maybe start a new thread) and I'm happy to help as much as I can.
Status of iRedMail??
Did this project get stuck in the transistition to TKLDev? Are you still looking for a sponser?
I started looking for a TurnKey GNU/Linux solution for handling mail when my homebrew server started receiving a lot of Phishing messages. At first I worried I had been hacked, but that seems not to be the case. I just need better spam filtering. iRedMail seems to have many of the features I'm looking for. If no one else is working on this currently, I could take a stab at rolling a TKLDev version.
Information is free, knowledge is acquired, but wisdom is earned.
I say go for it John! :)
So I say go for it if you are keen! :)
Status of iRedMail
Status of iRedMail - or any mail platform really such as Axigen mail, this is defiantly a much-needed appliance.
Unfortunately Axigen is "propietary license"
Unfortunately Axigen is "proprietary license" so that's not an option. We only provide appliances containing open source software. Although we do have intention to provide a Docker host appliance at some point. So once that's available, it should be a pretty easy install.
Although you are right, it'd be great to have a mail server appliance. Unfortunately, we have a lot going on behind the scenes. So to get it added to the library any time soon, a community member will need to step up and do the work.
Add new comment