Debashis Chowdhury wrote: I mean to say, after installation of an app, suppose i want to start or stop the working process of that app. How can i do so? For example, the content filter app has the facility to start and stop the working process.
Yup, the above PPTP example will show you the way.
Means, how can i execute a command in shell internally with the help of app which will enable or disable a process.For example, enabling/disabling a cron script by executing command internally through an app.
For normal daemons (in /etc/rc.d/init.d), follow the PPTP app as an example. In general, you can execute commands using the Shell class. Here's an example:
// B O O T S T R A P
Most of that thread seems to cover Fedora. The SOGo document for Openchange install doesn't take Fedora into account, only RH/Cent and Debian, and even then it's unsure of Debian to some degree. I think the SOGo team will likely have done an install test on RH/Cent, so there's a possibility is could work on Clear.
The implementation will get done in Fedora before it trickles down into RHEL, hence the Fedora discussion. Samba 4 will certainly build, install and seem to run just fine on RHEL/CentOS/ClearOS (that has been in the case in ClearOS 6 since October). It's that library issue that's a show stopper.
The Kerberos issue mentions that the MIT and Heimdal implementations don't play well together in certain situations, so I'd need to know what those situations are. I'd be looking for any situations relating to a standalone mail server.
The repercussions are a bit murky to me too, but it's certainly something that stops us from shipping it as a commercial product.
I can understand why you wouldn't consider it for a production server
If there's hesitation by the Fedora team to ship Samba 4 with AD/DC support, then that's a red flag to me. It's not even ready for Fedora
As it seems I'd have to drop using OpenLDAP in favour of Samba 4 and its internal LDAP
Yup. That will make a lot of people hesitate. It's one of the reasons we went with a driver-based solution in ClearOS - pick OpenLDAP or Samba 4... most the apps support both out of the box.
We will continue to chip away at the developer documentation as time permits. It's a high priority, so it won't stay stagnant.
1) How apps establish connection with core function after installation? What is actually executing internally?
4) Where the form datas are being stored after submission?
I'm going to answer 1 and 4 together.
Take a look at the PPTP server app. It's simple to understand, but still has enough complexity to make it a good starting point. Ultimately, a web form submission runs a bunch of API calls. For example, when a user submits the PPTP settings through the web form, the CodeIgniter framework sends the information to the API with the following block of code in the controller/settings.php file:
The API (in library/PPTPd.php) does the actual configuration change. In other projects, configuration changes are written to some kind of internal database, and then the configuration file is re-generated. In ClearOS, the changes are written directly to the configuration file.
2) How to enable(start) and disable(stop) the working process of an app after installation?
Do you mean how do you start and stop a daemon? If so, take a look at the /var/clearos/base/daemon/pptpd.php file (if PPTP is installed) as an example. You will need to create a similar configuration file for your daemon. Next, follow the controllers/server.php example in the PPTP app. If you get stuck, just let me know -- this answer should really be a standalone document (not just a handful of sentences!)
3) How to enable / disable a core functionality with the help of an app?
I'm not sure what you mean here. What app are you building?
Keep the questions coming, I'm more than happy to help!
Current ClearOS cyrus-sasl is 2.1.23 (full style 2.1.23-13.el6_3.1.x86_64) according to rpm. The version on the Project Cyrus website is 2.1.26. Is there likely to be a significant difference in the dependencies from .23 to .26?
Then that's very likely not a problem!
same here. I installed ClearOS 6.4 new, with all upgrades, then I transfered a zarafa 7.0-Installation von ClearOS 5.2. Had to unhook users and hook to the storages.
Everythings looks good, but its not possible to send mail to users.
Tried with fetchmail and on konsole with username, username@localhost, email@example.com: nothing works
So 09 Jun 2013 16:15:40 CEST:  Starting worker for LMTP request
So 09 Jun 2013 16:15:40 CEST:  Failed to resolve recipient firstname.lastname@example.org
So 09 Jun 2013 16:15:40 CEST:  Requested e-mail address 'email@example.com' does not resolve a user.
So 09 Jun 2013 16:15:40 CEST:  Client disconnected
So 09 Jun 2013 16:15:40 CEST:  LMTP thread exiting
Jun 9 16:14:59 clearos postfix/pickup: 6B1C234C04ED: uid=0 from=<root>
Jun 9 16:14:59 clearos postfix/cleanup: 6B1C234C04ED: message-id=<20130609141459.6B1C234C04ED@clearos.hostname.com>
Jun 9 16:14:59 clearos postfix/qmgr: 6B1C234C04ED: from=<firstname.lastname@example.org>, size=422, nrcpt=1 (queue active)
Jun 9 16:14:59 clearos postfix/smtpd: connect from localhost[127.0.0.1]
Jun 9 16:14:59 clearos postfix/smtpd: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 <email@example.com>: Recipient address rejected: User unknown in local recipient table; from=<firstname.lastname@example.org> to=<email@example.com> proto=ESMTP helo=<localhost>
Jun 9 16:14:59 clearos postfix/smtpd: lost connection after RCPT from localhost[127.0.0.1]
Jun 9 16:14:59 clearos postfix/smtpd: disconnect from localhost[127.0.0.1]
Jun 9 16:14:59 clearos postfix/pipe: 6B1C234C04ED: to=<firstname.lastname@example.org>, orig_to=<username@localhost>, relay=mailprefilter, delay=0.29, delays=0.23/0/0/0.05, dsn=2.0.0, status=sent (delivered via mailprefilter service)
Jun 9 16:14:59 clearos postfix/qmgr: 6B1C234C04ED: removed
prashanth wrote: Can u give me clear details about the configuration and implementation of coovachilli and radius installation
I have never tried it, so it's up to you to do the open source heavy lifting!
- The forum is definitely moving to other hardware. Thanks to some of the benchmarking done over the last few days, it was discovered that the I/O performance on the current machine is terrible - 3 to 5 times slower than comparable machines.
- If we can't get good performance out of the forum software, we'll have to move to an alternative. More hacking around is required to answer that question though.