Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - seati

Pages: [1]
1

But you don't have to create a new template for each site!
You can create just one template for all other sites.
So you set and use the same template for that customized sites.
You only need to create a new template just when you have a new type of customization. For a new site, or new group of sites.

I don't know what bug are you mentioning, but the templates are a feature for the panel.

Again, a template should be "re-usable". Have you every used nginx? In nginx there's no such thing as a .htaccess file! All redirects, rewrites, etc. need to be in the .conf file!
We host lots of websites with custom redirects, or custom rewrites! Thinking that WordPress is a "standard" or that all websites should expose URLs is a mistake!

A web based control panel should assist server admins to execute some tasks easier and in a more friendly way, but shouldn't imply that all server admins are dumb users who can't log into a shell and run commands or modify files! If I wanted a "fool proof" system where everything is just "point and click" I would get a Windows server and not a Linux one!

Yes, the fact that it "needs" to overwrite all configs every single day and doesn't perform any previous checks and imposes this as a "rule of thumb" is a BUG, not a feature.

2
The CWP dashboard now rebuilds all sites daily.
This means that if you have any previous customizations, you cannot do them directly in the Apache server configuration files.
You must create the customizations only in cloned template files for this purpose.
You did it?
What types of customization have you done?

Did you read all previous posts? A template shouldn't be something that needs to be created for each website, the definition of "template" in computing is:

a preset format for a document or file, used so that the format does not have to be recreated each time it is used.

So if we need to create a "template" for each website, then it's not a template, but a custom config.

There might be a thousand ways to go around this BUG, but the main purpose of this (and any) community forum is to get feedback so you can create a better product.

My scripting solution works for me, I can go to bed right now knowing that the websites will be up and running 24/7 (I even added a custom check that runs every minute, so the longest the websites can remain offline is 59 seconds)... But it's a hack, it's not a real solution.

 I even created a crack for CWP that could allow me to use Pro features without a Pro license (never released it and I am paying for my pro licenses), so the fact that something "can be done" doesn't mean that it "should be done"... or at least, that by doing things a specific way doesn't imply that it's the right way to do them.

Again, my hack works... but I have mixed feelings about having to do some custom coding to go around a bug that wasn't there... if CWP had rebuilt vhosts from the beginning, then it would be my choice to do some custom coding, go the "cwp way" or install another panel. But the fact that this "feature" (a.k.a. "bug") appeared out of nowhere with the last update and without any previous notice is what troubles me.


3
you need to use make all configurations in custom vhost templates...info about this is on cwp wiki.
Manual changes in the path or anything else in the vhost files are BAD and you should never do it.

A template is supposed to be something that you can use several times and that just gets the "custom" info replaced... or at least, that's what I understand for "template". When you have to create a "template" for each and every single site that uses a custom rewrite, redirect, directive, etc. then it's a custom config, not a template.

The RIGHT way for it to work (hope CWP staff reads this) is to:

1. Have a templates section as it is right now.
2. Have a CUSTOM CONFIG section for each website.
3. Have the vhosts "builder" load the template, replace the "regular" info, check if there's  a custom config for this website and if there is, then include such config in the vhost config file.

4
What a pain in the butt!

For some of us who use nginx as default webserver, there's no such thing as .htaccess. Therefore all redirects, rewrites, etc. have to be written to the vhost conf file. Creating a separate template file for EACH website based on their rewrite/redirect needs seems like too much work to do.

So far, the only viable solution that I've found is to keep a backup copy of the vhosts' conf files and created a script that will run periodically to match md5sums and if some file is different, it replaces the current file with the backup and then reloads nginx.

You can use the following command to freeze the any regular file, preventing any changes in it:
Code: [Select]
# chattr +i /path/to/file
Use it in a controlled way, knowing when to remove the immutability of the file, for example, when you need to change it.

When you want to change that file, just issue the command:
Code: [Select]
# chattr +e /path/to/file

The right command to be able to edit the file again would be:

Code: [Select]
# chattr -i /path/to/file

The "+e" switch is related to extents...

As to why I went the "script way" is because if something "changes" in the way nginx is set up (like for instance, where the private keys and certs are stored), I always have a "backup file" to compare and diff.

5
What a pain in the butt!

For some of us who use nginx as default webserver, there's no such thing as .htaccess. Therefore all redirects, rewrites, etc. have to be written to the vhost conf file. Creating a separate template file for EACH website based on their rewrite/redirect needs seems like too much work to do.

So far, the only viable solution that I've found is to keep a backup copy of the vhosts' conf files and created a script that will run periodically to match md5sums and if some file is different, it replaces the current file with the backup and then reloads nginx.

This update was (from my personal point of view) irresponsible, as it has brought too many issues for server administrators. Rebuilding vhosts should be something that server admins could do if needed, but that wouldn't be done by the update cron.

I'm surprised that no one from CWP has jumped in to explain if this will be a permanent "feature" (not to say a BUG).

Pages: [1]