virtual host directives and similar situations

[admin]

how-to, conflicts, dont want to screw this up, documentation, whm setup

[admin]

curious to know if undocumented features mean that I can assume that standard whm protocols apply? My understanding is that cloudlinux changes the use of some functions and file paths. I do not wish to start mucking that up, but Im finding no outline of differences in regards to use for what I would think are common place features in mass use. Is it that cloudlinux doesnt have enough adoption to merit larger efforts in documenting common use scenarios and their entanglements with your core changes, or am Im just overthinking this???

case in point--Virtual Host Directives:
Ive found all the info I need and Im ready to move forward with editing based on cpanel and apache documentation. However, there is no info on the subject matter fr om cloudlinux.
Methods found:
1) using the pre and/or post includes within whm
2) https://Modify Virtualhost Container... Include Files
Which is the recommended path for cloudLinux? Im uncertain because Apache, which would be the authority, gets very specific down to the user level of the file location. However, this may not fly with the unique user isolation structure of cloudlinux. Has no one ever asked this question?..as prolific as this question is online I doubt it hasnt come up before in regards to CL, so why not a trace of info?

Another similar situation is csf. no real commentary fr om either side on which csf recommendations still apply. Certainly, cloudlinux could say this is 3rd party and not their responsibility, but their is nothing from your company that I could find at all...I find nothing other than what csf has generally splashed into their app and quite a few of their notes seem to be outdated. Ive now figured csf out with 80% certainty on which of the server recommendations are needed and which are obsolete. However, I dont know what would have happened if I would have simply tested out recommended changes without regards to how CL changes scope. Would it have broken functionality? Inquiring minds want to know.

Warning: Here is wh ere the rant starts.

CloudLinux needs to have some in-house people walking through common popular use scenarios and mapping this stuff out. At the very least there should be some basic guides. This is what makes your older competitors a great choice, because the masses have had years to do this for them. Additionally, most of the server tools and software in the market are made for the older os, so your directly by design breaks those functionalities, but you never took the time to clue us in on wh ere these breaks occur. Your company, to me, should be the hungry upstart competitor that doesnt have that luxury of waiting for its user-base to do the documenting for them and therefore you should be offsetting the lack of information with internal effort of developing documents for practical use with existing software and server tools.

It feels like you built a better os that no one knows how to use and no one that does is actively sharing. Maybe those that have already been down the road Im now traveling are like me; just too pooped to do anything else after an all day discovery session in figuring out whats what in CloudLinux. They do say that all the best things are kept secret, so maybe thats a kudos to what youve built. However, probing your system without even some basic clues makes cloudlinux a daunting task. Dont get me wrong, I like what youve made but I think your company can do better to contribute to user case scenario documentation considering that this is a paid software.

Im now too invested to want to turn back, but by no means am I a super-admin that can figure all this out on my own. This rant is my plea that you please start
investing in documentation. Dont know how big of a budget CloudLinux has, but you look to be doing well enough to afford a small 2-3 person team that approaches documentation from a small business perspective. If Im wrong and theres no money in CloudLinux, then I apologize. Let me know, so I donate towards a box of doughnuts and some coffee for the late night code sessions in moms garage.

***Remember, you may make most your money from the big guys that buy hundreds and thousands of licenses at a time... but those guys exist to sell licenses to me and other small business like me that dont have teams of IT staff to mitigate the lack of documentation.

[iseletsk]

> My understanding is that cloudlinux changes the use of some functions and file paths

Not really. We took great pain to make sure that everything works the same as before, that paths stays the same, and pretty much everything works the same.
When we find situation where it is different -- we are pretty much always assume it is a bug on our side, and corrected.
This is why you dont find any such documentation --> there are no specifics on virtual host path/files/templates/include files
There is no difference on CFS (we actually worked with them to achieve it) when operating on CloudLinux
Any time we find something that would require as to document "This is how it works on CentOS, and this is how it works on CloudLinux" --> we go back to drawing board, and work on making sure it works the same and we dont need to document it.

[admin]

I may not have been clear, as Im pretty sure there are options in cpanel and recommended settings in cpanel that are not necessary to set due to fact that CL LVE already performs certain security patches. Additionally, turning on setting to create pseudo-isolation that other providers have created would be duplicitous and therefore, in my eyes, a potential for conflict. Is this line of thinking correct?

If it is correct in thinking this way, then not having a definition of these potential conflict of feature sets that would redundantly attempt to create what the LVE kernel and system architecture already have done may cause harm. I dont know...because differences in file structure for stock vs CL are not outlined and potential for conflicts are not address in clear fashion that can be easily found and/or assimilated.

Final question to ensure Ive been thinking of this all wrong and there is actually no incompatibilities as you say...
1) Can I make every recommendation made by cpanel to enable all switches recommended for isolation, even though the recommendation are for users that are not on cloudlinux.
2) on CSF there are security parameters that are instructed as best options, but the some of these security options involve turning off features that would expose entry points where attacks can exploit non-isolated server environments that fit the description of a non-LVE sys. Otherwise, if their recommendations are valid, then what is purpose of the CL? ---for a more direct phrasing: their instructions tell you to close a door that is supposed to already be closed.

There may be no such thing as too much security, but it would be nice to have documentation of the interaction between CL, cpanel and core plugins so that a greater understanding can be achieved.

[admin]

to add to reply...I do understand that you are stating that pathways for Apache are the same, so at least for virtual host directives I know what steps to take next.

[iseletsk]

The only two thing I can think of is jailshell vs CageFS and mod_ruid2. Even there we automatically disable jailshell when CageFS is installed

http://kb.cloudlinux.com/tag/cagefs/

And incompatibility of mod_ruid2 & various components is covered within components docs:

http://docs.cloudlinux.com/index.html?php_selector.html

http://docs.cloudlinux.com/index.html?compatiblity_matrix.html

I really don know about about other unresolved potential conflicts. We are missing "Getting started guide". We have been discussing it for past 2 months, and will soon start working on it. Yet, overall our dev. motto is "Things should work same as before, only better"