PANEL_PATH should default to /opt/sentora

[cloakedcode]

As a sysadmin I would really appreciate it if sentora was not installed to /etc/sentora but rather /opt/sentora.

It is the linux standard that /opt contain third-party software, as opossed to what comes with the base distro install. See here: /opt. On the other hand, /etc is reserved for configuration files only and should certainly not contain files that will be served through apache, /etc/sentora/panel for example (/etc definition).

If all that's required to change the installation path is that PANEL_PATH be modified, this seems like a nobrainer. Unless this is outright rejected, I'll submit a PR.

[allebb]

It makes sense, feel free to open a PR, there are also potentially changes needed over at the main sentora-core repository (where paths may have been hard-coded - Not that they should have been as there is a system option that should be used!) but I agree, it's a good idea, we just need to manage the transision!

So thinking along the lines of trying not to break too many third-party modules (again, where paths may have been hard-coded) I guess we could create a symlink to ensure that things don't break whilst module developers etc are working on our advisory notes? - Not being a system administrator I'm not the best person to say whether this is the best idea (creating the symlink) but in my opinion is a possible short-term transmission fix (move files to /opt/sentora and then create a symlink in /etc for 'sentora'... how does that sound? )

Personally I think this would be the best way to tackle this initially to ensure that modules and code don't break until we've had a chance to properly test and third-party developers have had a chance to act on our mailing list notification (change any paths in your modules where you've not used our system option values.) - We'd then look at removing the symlink in future.

Your feedback/opinions would be much appreciated @cloakedcode,

Cheers, Bobby (ballen)

[bambusoft]

Also consider that PANEL_DATA should default to /srv/sentora

[allebb]

Well if you ( @bambusoft ) and ( @cloakedcode ) can decide on 'the best' installation directories that would be great, I wouldn't class myself as a Linux SysAdmin really so if you guys could give us feedback with regards to best practice that would be great!

Unless I'm missing something at the moment it seems like @cloakedcode is saying that we should move /etc/sentora/panel to /opt/sentora/panel and @bambusoft is saying this shouldn't be /opt but actually /srv?

Which should it be guys?? :)

[bambusoft]

I recommend: /etc/sentora => for configuration files /opt/sentora => for source/compiled /srv/sentora => for hostdata /var/senora => for log+mail and not shareable data

[5050]

why not /var/www (which is already predefined on most distrib) for hostdata ?

BTW, changing all dir is a huge work and I will not rework it for 1.0.0, or before we have a minimum tool to be able to do checks for no regression.

[bambusoft]

There is currently no consensus on how this should be done, but if we want to consider TLDP or Linux Foundation FHS recomendations then: /var is for system variable data and /srv is for site specific data.

I made my own linux distribution following FHS v3.0 and this part is not in conflict between The Linux docuemntation project (TLDP) and the Linux Foundation Filesystem Hierarchy Standard (FHS)

I agree wit @5050 this must be considered for a future version

[allebb]

Lol... Like 5050 said, the other main Linux distro's (CentOS, Debian, Ubuntu etc) are using /var/ for host data by default and we already use /var/sentora for host data so I'm sure that this is one of those arguments that I guess we should get more input on.

On 11 November 2014 15:22, MARS notifications@github.com wrote:

There is currently no consensus on how this should be done, but if we want to consider TLDP or Linux Foundation FHS recomendations then: /var is for system variable data and /srv is for site specific data.

I made my own linux distribution following FHS v3.0 and this part is not in conflict between The Linux docuemntation project (TLDP) and the Linux Foundation Filesystem Hierarchy Standard (FHS)

— Reply to this email directly or view it on GitHub https://github.com/sentora/sentora-installers/issues/31#issuecomment-62561811 .

[bambusoft]

Yes, and personally, I don´t have any issue with actual filesystem hierarchy in sentora project... but considering @cloakedcode suggestion: following TLDP or FHS then we need to attend /var recomendation:

/var ... "Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list."

[cloakedcode]

/var/www is the default directory for apache. That is, apache will serve the contents of /var/www as a directory, not individual sites. If you were going to use this directory, you would need to delete/overwrite the default vhost. Other than that, go for it!

I combed through the installer and it looks like it's creating directories in /var/sentora that the individual packages create (e.g. /var/sentora/log/proftpd vs. /var/log/proftpd). The last thing I want when I install software on a server is it taking over my system and changing the behavior of other software, especially standard log paths. I cannot discourage this enough, there is no reason to change the default config of other software in this manner.

Other than /var/sentora/hostdata I don't see a need for a /var/sentora and it should be /var/www/sentora or /srv/sentora. As @bambusoft just pointed out, /var/sentora shouldn't exist as a directory directly under /var.

/etc/sentora and /opt/sentora should exist and follow @bambusoft previous suggestion.

Thoughts?

[cloakedcode]

@5050 What exactly needs to be done before v1.0.0? I don't see a milestone for it or any mention of remaining features/bugs. I'd love to help you get there!

[bambusoft]

@cloakedcode is right, i'm updating my suggestion:

I recommend: /etc/sentora => for sentora configuration files /opt/sentora => for source/compiled /srv/sentora => for sites hostdata /var/backups/sentora => for backups /var/log/sentora => for log /var/mail/sentora/vmail => for mail /var/tmp/sentora => for temp

As @bobsta63 said, we should get more input on this, why not open a forum section?

[bambusoft]

@5050 I think the most simple but unclen way to do this after sentora-project consensus is: a) create all dirs and leave a symlink in the actual /etc/sentora & /var/sentora directories pointing to those dirs b) Update documentation on this change and wait for all hard coded references to be changed c) Remove symlinks in future 1.0.x releases

comments?

[5050]

There are also some considerations to be included in directories choices : actually, all files managed by Sentora (logs, hosting, vmails, temps, ...) are centralised in /var/sentora directory. (and It helps to manage them). But it is almost usual to enable users of mutualized hosting to have an access to their own logs and vmails files. We have had a speak about that, and I think in a next version we will have to enable the admins to choose between a centralized place or a client space for them.

I think time will be better to redesign file place at this moment rather to produce two time changes and work about it. It also leave us time to take good choice and not change again. (Also, I am a bit tired to do change and check again the installers each time under 4 OS x 2 (64/32b) + some VPS hundreds of time since september, delaying the output of first release each time, for points that are now more improvements than bugs).

[allebb]

I agree Pascal - Let's just put this one on the back burner until the next release as these changes will mean re-doing all the testing again and will further halt this upcoming release.

On 11 November 2014 18:39, Pascal Peyremorte notifications@github.com wrote:

There are also some considerations to be included in directories choices : actually, all files managed by Sentora (logs, hosting, vmails, temps, ...) are centralised in /var/sentora directory. (and It helps to manage them). But it is almost usual to enable users of mutualized hosting to have an access to their own logs and vmails files. We have a speak about that, and I think in a next version we will have to enable the admins to choose between a centralized place or a client space for these.

I think time will be better to redesign file place at this moment rather to produce two time changes and work about it. It also leave us time to take good choice and not change again. (Also, I am a bit tired to do change and check again the installers each time under 4 OS x 2 (64/32b) + some VPS hundreds of time since september, delaying the output of first release each time, for points that are now more improvements than bugs).

— Reply to this email directly or view it on GitHub https://github.com/sentora/sentora-installers/issues/31#issuecomment-62594675 .

[cloakedcode]

@5050 @bobsta63 What is upcoming? Is there a roadmap? What still needs to be done for this next release?

[allebb]

We are working on mainly getting bugs in the bug tracker sorted for this first release, then we plan on looking at the next release and we'll be adding more features but ultimately I'll start working on Sentora 2.x.x (the new major version) after this release, the other guys will continue to work on bugs and small features for Sentora 1.x.x.

We are actually currently putting a roadmap together in our staff forums and hopefully we'll finalize it and publish it soon!

Hope this helps,

Cheers, Bobby

On 11 November 2014 19:01, Alan Smith notifications@github.com wrote:

@5050 https://github.com/5050 @bobsta63 https://github.com/bobsta63 What is upcoming? Is there a roadmap? What still needs to be done for this next release?

— Reply to this email directly or view it on GitHub https://github.com/sentora/sentora-installers/issues/31#issuecomment-62598157 .

[5050]

@cloakedcode The better you can do to help is to beta test install on VPS, check as everything as you can and report in the forum what you tested, what is ok, what is not, and if you know, proposal to fix if required. See here : Sentora Beta Testing 1.0.0

I tested all 4 OSes in 32b and 64b, mostly in VM (VirtualBox) + DO droplets, but there are a lot of VPS with small tuning that may break details. As example, I'm battling with Crissic VPS that seems have a non-standard configuration of Ubuntu, with even all default cron job disabled. :-(

Do not forget to mention Installer version and VPS hoster if anything not standard is discovered.

[andykimpe]

for me I recommend:

/etc/sentora => for sentora configuration files /opt/sentora => for source/compiled /var/sentora => for sites hostdata /var/backups/sentora => for backups /var/log/sentora => for log /var/mail/sentora/vmail => for mail /var/tmp/sentora => for temp