[RELEASE] Installatron (DirectAdmin auto script installer)

what now?

l0rdphi1 said:
Turns out he was not using the latest version of DA :D
Click to expand...

I updated DA
I rm -fr /usr/local/directadmin/xserv
then I re-ran installatron.sh

Now when I try to login I get

ERROR: DOCUMENT NOT FOUND

:o
 
The skin mods are overwritten when you update DA :) Simply reapply them as you initially did. You didn't have to rm -fr either. I just had you doing that earlier when the SH script wasn't working on FreeBSD - I didn't really know what it put in place and what it didn't.

Once John adds a real plugin system this skin jumble won't happen.
 
Last edited:
I was thinking we could create a files_custom.conf file in the skin directory... The da skins won't have that file, but it would always be checked first. That way, if you want to override anything in the skin, no matter on the update, you can. IE: HTM_XSERV.

So... that could solve that issue, but then there is the fact that you'd want to have links in the skins, right? So we'd need some file somewhere for DA to add to some spot in a skin.

Another thing, do we want to have plugins work for *all* skins without having to install it? Like a global files_global.conf which would not be located in any skins dir. but some "global" skins directory for all skins to use (not sure how that would work for skin consistency).. Maybe would could add CMD_PLUGINS for *all* skins which would request one token, |PLUGINS| or something like that, then DA would go to the global directory and get all plugins installed, add the links, and use the files_plugins.conf from that directory,whereever it is. If we did that and forced all skins do have an empty CMD_PLUGINS with |PLUGINS|, then no matter what skin you installed, all plugins would show up all the time..

thoughts, comments, suggestions?

Let me know how you want to to work, and I can wrap DA around that.

Options, many can be used in combination:

1) All skins can use files_custom.conf, whcih should not be included in the tarball, but can be created to have more authority than the other 3 files_*.conf files.

2) Have a plugins directory somewhere which DA will parse. All skins would have CMD_PLUGINS and DA would fill the |PLUGINS| token depending on what plugins were installed.

3) Have a series of global tokens: |PLUGIN_1|, |PLUGIN_2|, etc.. which are loaded on *all* pages. Leave it up to the skin designer where they want to put those tokens. The tokens could include links to files stored in 1) .. or the plugsins directory... could be incorportaed with 2)..

John
 
Let's have a plugin directory, somewhere like this: /usr/local/directadmin/plugins

And, inside this plugin directory, have a .conf file for each installed plugin.

Taking itron.conf:
name=Installatron
location=/usr/local/installatron
language=php
description=Installatron adds the ability to install a growing list of web-scripts at the click of a button.
Click to expand...
'name' simply referrers to the plugins name.
'location' is the directory to which the plugin was installed.
'language' referrers to the language in which the plugin was written. (for execution purposes.)
'description' referrers to the description for the menu item.


As for the menu, I'm not exactly sure whether a "Plugins" page is needed for a list of all installed plugins, or whether each plugin should be integrated into the main DA menu. It works both ways. Personally, I like the integration method :) But with integration, we have a problem: where will the plugin menu items be placed? should they just be appended to the end of the DA menu token? (Forgive me, I'm not sure how menus work in skins.)


As for the plugin page engine, 'CMD_PLUGIN' could work; calling 'CMD_PLUGIN?id=iTron' (or something similar) tells DA to look in /usr/local/installatron for a file called "loader" (or something similar). Then DA executes the "loader" file according to our 'language' conf value.

Another approach to the page system is your "files_plugins.conf" idea. This seems more flexible. So, in addition to the '/usr/local/directadmin/plugins/itron.conf' files, we also need a /usr/local/directadmin/plugins/itron.files (or similar) file. This .files file is as "1)" is in your post :)

Given the .files approach, I suppose we could substitute the above file-per-plugin approach with a single, "global" files_plugins.conf file in the plugins directory (or skins directory), but I wouldn't want one plugin to potentially screw-up others.


On Skinning. I'm all for some type of global skin situation. I've stated in pervious posts we need some kind of template file reusable by all skins, so skins need no mods, ever, to support any plugin. Previously I described a file as:
|HTM_USER_TOP|
|?TREE=...|
|OUTPUT|
|HTM_USER_BOTTOM|
Click to expand...
Although I wish I could edit where the ... is ;)


Good luck, John. I really hope this is implemented soon. Let me know if I can help in any way. :)

Cheers, Phi1.
 
I suggest not to use global list of plugins. Some plugins should be added to user menu, some to reseller menu, some to admin menu and skins are different. And for mail-only skins it should auto-detect only plugins that has anything to do with email. That system might create more problems than solve.

Better make it skin author's resonsibility to detect plugins instead (by checking if some files exist), like it is right now.

And installatron is a well known plugins so i suggest to add simple php code to default and power_user skins to check if /usr/local/directadmin/xserv/loader.php exists and if it exists show menu item for installatron.
 
Last edited:
One side of me agrees with you, CyberAlien, while the other does not. I feel for the sake of customizability, which is a front DA seems to have pushed, per-skin plugin menu manipulation is the best way to go. However, the other side of me says, "What the hell?! That's bad OOP!"; there needs to be some kind of reusable plugin menu apparatus. I'm really not sure which way to sway.

Nonetheless, I feel very strongly the backend-page-handling system should be a global system or per-plugin-defined system, as I talked of above. Skins should not worry over what plugins need what pages in the .conf files.

The same goes for the reusable template, it is required so that plugins can share a design with a skin. Also the per-plugin .conf files need to remain. Under CyberAlien's approach, skins would check the plugin .conf file to decide how to handle a plugin.

So the question is: let plugins handle their own menu item in a global context, or let skins do it for them on a per-skin basis?
 
l0rdphi1 said:
The four licenses I've sold so far really confirms that.. *sigh* :rolleyes:

*cough*
Click to expand...

Still waiting on better integration and more scripts here.
My company is still interested, but there are some more pressing issues we're working on at the moment.
(Integrating our site and DA, our 'to-be' billing solution Clientexec and DA... (Note: at the moment they're at version 1.1.1, this version is of no use to most company's, so don't go buying it based upon my advise :D))

Can't there be a number of plugin slots everywhere ?
Where the plugin script creators can decide where exactly they are, just let the skin creators place a possibility for plugin script links in their template designs, so that it's possible to install a certain number of plugins... (am i making sense here ?)
 
Icheb said:
Can't there be a number of plugin slots everywhere ?
Where the plugin script creators can decide where exactly they are, just let the skin creators place a possibility for plugin script links in their template designs, so that it's possible to install a certain number of plugins... (am i making sense here ?)
Click to expand...
That's possible. But I'd hate to limit the number of plugins one can install :)
 
l0rdphi1 said:
The four licenses I've sold so far really confirms that.. *sigh* :rolleyes:

*cough*
Click to expand...


You kidding right?

I would think you would sell licenses hand over fist. How many people downloaded it when it was free (beta)?
 
It looks as though I had ~59 downloads of the final beta.

And DA has sold about 2450 some licenses? (John?)

Hmm - I think a big factor is that anyone who hasn't looked in the 'Modifications / Add-ons' forum doesn't know about Installatron. Hmm...
 
Don't worry L0rdPh1l, it just needs time. I'm configuring 1.2 now, I'll post on how it goes :)

Matt
 
L0rdPh1l,

The script can't find any usable domains... but there are domains on the account. Everything else seems to be working fine.

Feature request: How can I change the icons that are displayed for the programs and the Installatron logo? I use HTTPS for my control panel, and I don't want users to be hassled by IE popups warning about non-secure images etc.

Thanks :)
Matt
 
If I symlink private_html to public_html on my DA server, will IE still complain because it's a self-signed cert?

Hmm.. I suppose we'll either have to purchase a cert for installatron.com (which is possible), or on a settings page in v1.3, allow you to enter a URI to an https image directory on your main domain, and then iTron will copy all its images there.
 
l0rdphi1 said:
It looks as though I had ~59 downloads of the final beta.

And DA has sold about 2450 some licenses? (John?)

Hmm - I think a big factor is that anyone who hasn't looked in the 'Modifications / Add-ons' forum doesn't know about Installatron. Hmm...
Click to expand...


I agree. Most people purchase software and never even look in the forums. Maybe DA good email admins (same as when DA updates) with links to Installtron, released skins etc etc. I think it would help DA sell more licenses. A lot of hosts use both Cpanel (god forbid) and DA and the more features admins know about DA (addons etc) the more they (and their customers) will like DA.

A few good press releases for Installatron would realy help promote IT and DA (move over Fantastico, theres a new kid on the block :-)
 
thoroughfare said:
The script can't find any usable domains... but there are domains on the account. Everything else seems to be working fine.
Click to expand...
Are you running DA version 1.21.2? Is it doing this for all accounts?
 
l0rdphi1 said:
If I symlink private_html to public_html on my DA server, will IE still complain because it's a self-signed cert?
Click to expand...

Yes I would think so.

l0rdphi1 said:
Hmm.. I suppose we'll either have to purchase a cert for installatron.com (which is possible), or on a settings page in v1.3, allow you to enter a URI to an https image directory on your main domain, and then iTron will copy all its images there. [/B]
Click to expand...

I think you should get a cert... then you can accept root passwords securely etc. I sell them for $39/year if you like :) Anyway, is there a work-around for the moment? Also, does iTron use Turck's MMCache?

Thanks,
Matt :)
 
You must log in or register to reply here.
Back
Top