New check command for web-add.sh #5
No reviewers
Labels
No labels
Bug
Doc
Feature
Forge
Mode
Cluster
Mode
MultiPHP
Script
Server
Web
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: evolix/evoadmin-web#5
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "ticket-37722"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I'd like to introduce a new fix command for scripts/web-add.sh,
which can be safely run when somebody overwrites symbolic links in
sites-enabled.
But there are many ways of doing this, it could be a command like
it is now, but it could also be a simple function that is called
anytime scripts/web-add.sh is run or a separate script that is
either run manually or through cron(8).
Any opinions or thoughts on this?
I commented the code with a "beware". The idea is good, but it should be used with precaution!
@benpro How do you view comments on the code?
@ -991,0 +997,4 @@
# Some people forget to use the --follow-symlinks flag with sed(1),
# thus not carrying changes over to /etc/sites-available.
op_fixvhosts() {
ln_vhosts_dir="$(echo "$VHOST_PATH" | sed 's/available/enabled')"
Useless echo? Missing last sed trail?
Should be:
Mostly me not completely used to bash again, I'll fix it.
@ -991,0 +1004,4 @@
do
vhost_name=$(basename "$ln_path")
mv "$ln_path" "$VHOST_PATH/$vhost_name"
Beware that operation can be dangerous. If people have modified the version in sites-available and sites-enabled, you should first merge the difference in the sites-available version, then do the symbolic link.
I'm thinking it could probably take a --dry-run flag
So what would the behavior be when using it from the web interface?
Huh. No need for that feature in the web interface.
This is for helping sysadmins only.
Yes you should add a
--dry-run
, or even should be the default.What's your preference:
--force
or--apply
?--force
is nice. (If you force, you must understand the consequences ;))Yeah but
web-add.sh fix --apply
makes more semantic sense in my mind,web-add.sh fix --force
seems to apply more to an operation that was aborted because of inconsistencies, but gives you the option to force break stuff? Likeweb-add.sh add-alias [alias] --force
would make sense.Well... Ok for
--apply
.See the latest commit for changes. I switched fix-vhosts to check-vhosts and added the -f flag to apply fixes.
@ -991,0 +1005,4 @@
vhost_name=$(basename "$ln_path")
mv "$ln_path" "$VHOST_PATH/$vhost_name"
ln -s "$VHOST_PATH/$vhost_name" "$ln_path"
You could also use
a2ensite
in place of doing a manual link.Good idea
Web wise I see the
web-add.sh
use the fix command before doing anything with an existing vhost, if it detects that theres a problem with the vhosts it should abort and tell the webpage to show "Contact your administrator, something is wrong with the vhosts".Alternatively this functionality could also be exported to
evocheck
but it would imply adding a dependency toevocheck
forevoadmin-web
.I agree.
Evocheck is already checking that with
IS_APACHESYMLINK
.So should we be just using that? Evocheck could be modified to add a --fix flag that automatically fixes specific problems. I'll have to look at the existing code first though.
No Evocheck isn't meant to fix things.
Fair enough, but should the code that checks if a fix is necessary use evocheck instead of my current implementation?
@benpro what do you think of the latest commit? (I'm not too sure how notifs work yet)
"/ServerName .*/a \\\tServerAlias $alias
missing the trailing slash?LGTM
Cool, @vlaborie what do you think? Anything sticking out?
If not I'll do one last round of testing.
WIP: New fix command for web-add.shto New check command for web-add.sh@romain any comments or is it pas pire?
Sounds good for me, you can merge your code.