Amahi Forums

Nice going guys!!

Per ichat's request, I updated the Amahi Roadmap page with my perspective of what should go into the version 5 that's brewing.

Hello all, - i've added yet a few ideas to the roadmap,

specially the idea of an amahi sublayer, would be a really valued addition to the procject,

if its possible to bundle all the distro-specific commands in a string-like file (resembling how language handling is done)
it would verry much help developers to port amahi to other distro's like the much spoken of ubuntu version.

this would require the knowlegde of a linux (distro) guru who truely understands the diferences between most common used distro's.
based on that knowledge we need to build a draft to explain what commands (for example the package-installer) are distro-specific and how we can handle different tools that have different commands but also display thair userinfo all in a different output, order and logics.

to make Amahi able to run distro-independent we should thus add some way of interpretation between the "management GUI's" and the actual system itself

this may not be a feature that is plausible to be in the Amahi 6.0 release unless there is a significant contribution in knowledge and code examples

wrt to the package installer: it is possible to install yum on Ubuntu, and I think this would greatly speed up development in that area: http://packages.ubuntu.com/karmic/yum (it is also available in older releases).

The differences between the distro's are not _that_ big, but as they say, the devil is in the details
The location of some config files might be different (can be resolved by symlinking or checking certain paths during the ./configure phase)
The tools are more or less the same. I've been using Debian on my local desktop (currently Ubuntu) and RH, Debian, SUSE on servers. The differences are really _really_ minor for normal usage. Tools are usually also packaged for different distro's (e.g. the chkconfig command on RHEL/fedora/centos which on Debian is the update-rc.d command, but you can install chkconfig on Debian as well - not sure about the other way around).
The main point however is versioning. You'll have to make certain that you will configure/install against the lowest common denominator.
That might lead to packaging the required version of $lib/$module/$tool in the Amahi repo. This _is_ to be preferred for users, but not for cpg who's footing the bill of the amahi repos. I wil ask for info with a dutch mirror maintainer (debian, fedora, centos, bsd mirror) how that kind of stuff is handled.

Personally I would like the hdactl stuff & the apps in /opt and userspace data in /mnt/data/($sharename) but that's a structure thing and highly debatable since it's based on personal preference. I might be able to discuss this with said maintainer or his colleagues (unix/linux gurus working for a _very_ reputable unix training/consulting/programming firm in NL) to think about the best way to structure this kind of application.

The main point however is versioning. You'll have to make certain that you will configure/install against the lowest common denominator.
That might lead to packaging the required version of $lib/$module/$tool in the Amahi repo. This _is_ to be preferred for users, but not for cpg who's footing the bill of the amahi repos. I wil ask for info with a dutch mirror maintainer (debian, fedora, centos, bsd mirror) how that kind of stuff is handled.

unless you would adapt the update pocess a slight bit...

if you use apt- for instance, you COULD use meta-packages hosted on amahi, and than use the ubuntu repos do download packages... install them, and than apply any modds in the conig of those packages if and where neaded... ...

in practice - you would have a virtuall repos for ubuntu files with amahi packages... and referals to ubuntu ones...
for example would install a hollow package that in its turing kicks of it WILL however makes the ubuntu part a complete diferent thing as regarded the packaging, even hough the sourcecode would be the same... meaing that a package maintainer should be devote entirely to that one distro... and keep track of any developments..

it aso means that 1 guy is also packagng scriptfiles all day.... and constantly checking if update x doesn't break feature y....

yet another concern of mine:

can anyone confirm if apache is running root ????

if this is so than why are we running both the system management console and the user-land apps with root:root,

is it not wise: to run a amahi-serv demon i.e: a custom really smal footprint httpd for the amahi-manager
and any apps that really must have root access.. nearly none should though...

and more standard configure apache for stuff like calandar's - php- stuff, and the like,

i.e. ive seen an amahi version of phpbb fyling from here to there... - i for one would never use it,
but also i would forbid it ran from the same deamon my server-critical app run on...

i even dare going so far as to say that phpbb latest -1 will allow me to gain root access to you server within a night's sleep if you run php without safe-mode (wich some other app in the reps require...

if we really run root (like i heared someone say) i think we should look for a way to fix this ...

because iirc - apach DID run root????

yet another concern of mine:

can anyone confirm if apache is running root ????
[...]
because iirc - apach DID run root????

Apache does not run as root. it runs as User apache with a group of apache

This behavior is configured in the file /etc/httpd/conf/httpd.conf

trying to find, - the link where i wread it to see if i misswread...

i think i might have...

but tnx for the quick reply it had me worried for a bit...

the main thing i never hear anything aboput is uniformity (is that a word?)

We have wonderfull apps! WONDERFULL management tools.. i truely think Amahi made my networking management a lot easier..

but one thing that didnt make it easier.. every app has its own layout, every tool has its own layout..
the minute you step away from amahi, you'll have to figure out how this app works and where that app's buttons are..

what we need, aside from yet more apps..
are a few php scripters, or whatever.
some that can make most of the tools (like a forum, mailclient, those kind of things) but then completely in sync with the amahi looks!
THATS something i truelly believe makes life easier for the n00bs we're targetting for..

also, we need people who are good in marketing, get this advertising machine running, find ways to generate some income, so that it pays for itself at least the costs of webhosting and such.

whilst i see tons of good idea's, i'd personally go for the stabilty way.. make sure everything is absolutely bug-free.
THEN go from there, and have everything "as we go" but make sure the base platform is ABSOLUTELY bug free!
(although i dare say it allready is? i never have any issues with mine, and i run F12)

also:
lets first make sure all the backup systems are working.
backup complete clients, media folders, documents, whatever..
also implement a way to backup the Server itself, in case of general failure.

ok, the common looks are going to be available in plugins (aka as "engines" in the new rails 2.3, and can be quite powerful subsystems). welcome "ruby scripters"

as for backups, keim captured some of the discussion in the IRC channel today!:

http://wiki.amahi.org/index.php/Backup_settings