Creating one-click app

[jaco]

Ok, I know that this topic may have several approaches, but I'm just looking one of them.

Let's suppose that you have all the files are needed, manually installed them to the proper directories etc and now it's time to package these files somehow and use this package to create the one-click app. How you do that?

Create an rpm file with a template spec file?
Create a tarball and you create a bash script to do the job?
Where do you upload the file?
How the hda setup is aware for the file's location?
How hda setup knows how to handle the file and scripts?
Where these scripts are located?
How the one-click app registers itself in the supported one-click apps?
Is really Megan Fox a man or not?

I've reached near the end and I can't proceed further, because I miss background informations how the platform works.

Thank you in advance for any help you may provide.

[bigfoot65]

Hello,

I will do my best to explain and hopefully answer your questions. You can also check out the wiki page, although it has limited info (http://wiki.amahi.org/index.php/Webapps).

First of all, you create a webapp with the name of the app, i.e. mediawiki. Next, open a terminal window and navigate to /var/hda/web-apps/mediawiki and download the app install package using wget. Then, you extract the files into the html directory of the web app, i.e. mediawiki/html. If the app extracts into it's own directory, you will need to move the files into the html dir manually. There are different methods to doing this as well.

So now the app files are located in the path of /var/hda/web-apps/mediawiki/html as an example. You run the install file from there via the web browser using the URL created by the web app, i.e. http://mediawiki. You may need to add more to the path, for instance if the app installs via install.php, the URL would be http://mediawiki/install.php. You get the idea. Also, if the app uses a database, then that will need to be created prior to running the app install. This is done via hda-create-db-and-user dbname.

Follow the app instuctions and when needed, supply the dbname as the database name, user, and password. Once it is installed and working, there are 2 different methods for preparing the install for packaging. One is using Patch and Diff (see http://wiki.amahi.org/index.php/Patch_and_diff). The second one is by determining what the difference in the files in html is from the original app archive. It is a bit more complicated, but works well. If there is a db, you will need to export the db via an app like Adminer or phpMyAdmin for use when you package the app.

Finally, most of this will aid in actually packaging the app via amahi.org. This takes practice. If the app is an RPM, then things are a bit different. I hope this helps get you started. There is more I need to explain, but for now this should get you going. Just remember, the app creation wizard at amahi.org has tips to help you along the way.

[jaco]

Hmm... I think that the things seems to be much more clear now.

If understand right, the quickest (and maybe the optimal solution) is just to create a tarball file that when it's extracted it creates a single folder that contains everything inside. Then upload it on a web server somewhere on the internet and pass it's url to the "Source URL" in "Download" tab in my profile. In that way no other install/uninstall scripts are required in the "Install Script" in "Update" tab, because the hda platform will download, extract and rename in an appropriate way the folder automatically. Of course, this stands only if the app doesn't require it's own db, where the things are a bit different, as there must be a script to re-create the needed users, tables etc.

In my app no db is needed, therefore I have only to create an amahi-appropriate tarball, provide a valid url (with an rpm naming convention for future updates), make some icons, write descriptions, fill the tags and finally leave the hda platform do the rest.

If that's it then it's easy or probably I've missed something again.

[bigfoot65]

Not quite, the original app source must be downloaded by the one-click app. A patch file will modify the changed files and if necessary, recreate the db. This is the business rule to ensure we keep the integrity and security of the original app in tact as much as possible.

I know it seems more complicated, but that is the policy set forth by the Amahi Team. It's not too bad once you have done a few. The only custom tarball is the patch file if needed and the sql to load the db. Otherwise, the one-click will extract the original files in the html dir. The install script will either patch or create the changed files as needed.

Hope that makes sense. I have attached one of the more simple apps I packaged and posted it hear for you to see how it's done. The text file has labels to match the app creation wizard. I typically do this before I actually create the app at amahi.org.

Like I said, it's not as complicated as it seems once you have done a few. I will be glad to help if needed.

[jaco]

well I did it as I described above. I didn't make any installation scripts. I just created a tarball with everything in it and it works well. Everything is extracted automatically in the html folder.

Could you possible or somebody else test it if everything is ok with installation?

[bigfoot65]

Hello,

I tried it and installed just fine. Looks nice. Does this app require access as root user to start the daemon? Amahi apps do not have the capability to sudo or have root access. I don't hve a way to actually test it as I do not have an account with rapidshare.

Users cannot see this app, only Amahi Team members at the moment.

[jaco]

I've made several changes in the code and in the web files so now there's no need for root privileges, like before. The apache's account privileges are now enough for the daemon to do whatever it needs.

I've also made some changes so now the web interface can start/stop the daemon. Therefore, there's no need for the daemon to register it's self as a service in init.d and the user can start/stop it remotely from the web interface. Of course, if someone wants it's still possible to manually start the daemon by adding the app in the init.d so the daemon will get also root privileges upon system start up, but I don't think it's important anymore. I've removed the path change in the app's daemonize init, so the executable stays in it's load path, therefore all the processed paths inside the daemon are now related to the start dir and not in absolute paths as it was before.

Actually, all the changes I've made in the codes were to meet the amahi's one-click approach. Finally I think this approach is very good, because it's simpler in installation and remove.

[bigfoot65]

Awesome Jaco. It should be a good addition to Amahi. I will see if any of the Amahi Team has the capability to full test it. If so, the can report the results here.

[jaco]

Thank you very much for your help, bigfoot65.

If any changes are needed then keep me informed.


And for the users that will find this thread by having the same questions, I have to say that there are two approaches regarding the one-click platform. The first one is from the integrator side that will try to integrate an already existing app in to amahi and the other is the developer side. The first one is much more complicated and you need to follow the bigfoot65's instructions and the second is much more simple and if you're developer then the only thing you must have in mind is to keep all the things in a single root folder (binary+web interfaces), write your code in such way to avoid the need for root privileges, don't use absolute paths, use the combination of bash scripts and php to interact with the system in order to get the status of your executed application. If you write your code like that it's very easy to integrated it in amahi's one-click app platform.