Automation and External Access

[chappy01]

Some suggestions on where to go with Amahi, although I have to say, I’m definitely not the person to implement the changes I see as necessary to move Amahi forward as a “simple user” platform. Just a few observations of things that would probably be helpful for people who aren’t necessarily techie.

• 1. External access to apps made easier. Automated editing of conf files.
  - Create a field in the settings where the user can define the domain name they will use to access their HDA from the outside world.
  - Add a selection for each application for “External Access” which then opens another text box to define the subdomain (defaulted to the current app name)
  
  2. Set rewrite rules in the conf files. Currently if you want to access any of your applications externally you must remember the full URL to the app, but if we moved to subdomains, you could have the home page automatically fill the tld in for you.
  - Example if you accessed the home page from http://hda/ then the home page would direct you to http://blog.hda/ however if you accessed from http://my.hda.com it would direct you to http://blog.my.hda.com.
  
  3. Implement a configurable single sign on. Usernames/Passwords would not only stay the same for any application, but would allow the admin to decide which users have access to what applications and what areas of the server. Would also only require one user setup instead of separately for each app. Also would allow only signing in to access the landing page and then quick access to any allowed applications.
  
  4. Security for applications. Do not use “default” username/password for administration setups. If using a single sign on this is not necessary. If no SSO is available, then we need a way to make the user define the admin username/password when installing the application for security reasons.
  
  5. Automate media scanning in applications. For apps such as Jinzora, Gallery, etc, we should be able to write the scripting to automatically include the correct path and scan for media during install. Allows for a true “one click install.”

I don’t know if any of this is possible or already being looked at. Just a few things I’ve noticed since using Amahi that I think would go a long way in making the platform easier and more friendly to use for those who don’t fully know or understand how to make the necessary configuration changes.

[moredruid]

1. External access to apps made easier. Automated editing of conf files.
* What do you mean with automated editing of conf files? This already happens (most of the files get values echoed from the database).

- Create a field in the settings where the user can define the domain name they will use to access their HDA from the outside world.
* If they have a valid domain. Some users think it's cool to have a bigcompanyname.com or whatever internally. Watch havoc ensue as soon as they get open to the internet. We saw this happen already, check the forums for the discussion on this (I think the domain was home.com). I think the current solution (yournick.yourhda.com) works fine. Have a DNS point to that with your TLD and you're done.

2. Set rewrite rules in the conf files. Currently if you want to access any of your applications externally you must remember the full URL to the app, but if we moved to subdomains, you could have the home page automatically fill the tld in for you.
- Example if you accessed the home page from http://hda/ then the home page would direct you to http://blog.hda/ however if you accessed from http://my.hda.com it would direct you to http://blog.my.hda.com.
* DNS is currently under investigation.

3. Implement a configurable single sign on. Usernames/Passwords would not only stay the same for any application, but would allow the admin to decide which users have access to what applications and what areas of the server. Would also only require one user setup instead of separately for each app. Also would allow only signing in to access the landing page and then quick access to any allowed applications.
* This would mean that the server should be aware on how groups/users are defined locally (it does) but also in every application (it doesn't). There is only 1 real solution for that and that is LDAP. The problem is that the apps need to support that too. Probably won't happen soon, if ever.

4. Security for applications. Do not use “default” username/password for administration setups. If using a single sign on this is not necessary. If no SSO is available, then we need a way to make the user define the admin username/password when installing the application for security reasons.
* Agree

5. Automate media scanning in applications. For apps such as Jinzora, Gallery, etc, we should be able to write the scripting to automatically include the correct path and scan for media during install. Allows for a true “one click install.”
* So tell me, what is the "correct" path to scan on my server? Have I stuck to the defaults? Then you're lucky and you're scanning the correct directories. If not, tough, and the user will think the application is broken. Some people have removed all shares, and substituted them with shares with the same content but in their own language. How would you catch that in a script? Of course you can run a find on /var/hda/files/ and get your info from that, but that may not be suitable - i.e. you have a bunch of *cough*private*cough* pictures you don't want in Gallery but they will be added automagically - imagine having that up on the internet.
No, automating that is not the way to go. Asking the user for the correct directory may be an option.

Don't get me wrong, I'm not torpedoing your ideas, I just give you my take on your points based on experience (both on Linux/services in general and Amahi in particular).

[cpg]

i think on one hand moredruid points out that these are all possible with more or less degree of difficulty.

however, this is a very crisp, very actionable feedback. some of the best feedback we have gotten in recent times and i think we should attack these areas - make them as easy as clicking a checkbox or entering a field, which i think is what he is referring to.

again, these are doable, as moredruid correctly points out, but we can do better, i think!

[chappy01]

cpg: thanks Not to say that I don't absolutely love the platform, because I do. Just a few things I have found that *could* be easier.

moredruid:
To clarify some of the things I mentioned.

1. We don't necessarily need to change the current setup for yournick.yourhda.com. More to the point was to create a check box that would automatically fill in the needed ServerAlias in the conf file. Right now (unless I've missed an update) to access any of the apps externally you must manually edit a file on the server to "allow" external access. The text box and definable domain information would still be for more advanced usage, such as for those (like myself) who have had many different server setups but have kept the same domain information. Granted it's not a true tld, I use DynDNS. Instead of having to remind, update, or change that information for all the people who access the server it would be nice to be able to define my DynDNS name on the server, then click a check mark on the app so it will automatically place the correct values in the file so ampache is now accessible from ampache.mynick.dyndns.com (or whatever is applicable).

3. You are probably 100% correct. I have been researching SSO standalone solutions to see if I could find one out there that would fit what I'm looking for. I have found 3-4 so far that will work and do not require LDAP, but so far they haven't fit the bill. A lot of install/uninstall happening while playing with them. If I do happen to find something that will work I'll be sure to document what I did and used for possible implementation.

5. Very good points made and things I didn't think of. So in this case the only way to make that work if for the install script to have another variable and user defined area, which might really defeat the purpose. Well, in my head it sounded like a good idea, LOL.

[moredruid]

On point 1: this explanation is more to the point I even agree (If not for myself, then at least for others that want to use the hda like this.

On point 3: heh, SSO is a very _very_ tough nut to crack. Even big enterprise solutions don't get it 100% right (though Citrix/RES Powerfuse come close, at least for - and there we have it - supported applications).

Some apps work with your Google ID, some with OpenID and there's a bunch of other projects. The point is that every app on Amahi must support this to work right. Probably the Google ID and OpenID and LDAP are able to understand each other, so you might be able to cobble something together to make that work (that would be a nightmare to do/maintain though), or you just go from the current setup to LDAP and if the app supports LDAP use it, if not dump the users and insert them into the database of the app. The main problem with this is application level permissions. You either have to define those in the LDAP schema too if you're being thorough or do it on the application level alone. Either way this is a logistical nightmare with 10 apps, let alone the wealth of apps Amahi has to offer.

On point 5 - I'm quite sensitive on privacy issues and I'm sure some people think I overreact haha
However - my girlfriends' business runs on that server (and our private stuff is on there too) and I don't want it exposed to the internet in any way (at least not publicly). I do have SSH open however that is shielded up so much (IPtables tarpitting, passwordless SSH login (PKI), hosts.allow/hosts.deny) that I don't expect someone to get in without jumping some major hoops. This is used only for remote maintenance/troubleshooting.