On updating a webapp-managed application (like mediawiki), the config line vhost_root="/var/domains/${vhost_subdomain_2}.${vhost_subdomain_1}/var/www/${vhost_subdomain_3}" (vhost_config_dir="${vhost_root}/conf") seems to fail with the attached error message. Installing a new application with this config seems to work like expected. Reproducible: Didn't try
Created attachment 257873 [details] Build output
* Fatal error: Bad value substitution: * Fatal error: section: [USER] * Fatal error: option : vhost_config_dir * Fatal error: key : vhost_subdomain_2 * Fatal error: rawval : \.${vhost_subdomain_1}/var/www/${vhost_subdomain_3} * Fatal error: Please note that webapp-config is not written in bash anymore * Fatal error: and that you cannot use the bash scripting features. What if you expanded those variables in the config file to their actual values? The warning seems to indicate that.
(In reply to comment #2) > * Fatal error: Bad value substitution: > * Fatal error: section: [USER] > * Fatal error: option : vhost_config_dir > * Fatal error: key : vhost_subdomain_2 > * Fatal error: rawval : > \.${vhost_subdomain_1}/var/www/${vhost_subdomain_3} > * Fatal error: Please note that webapp-config is not written in bash anymore > * Fatal error: and that you cannot use the bash scripting features. > > What if you expanded those variables in the config file to their actual values? > The warning seems to indicate that. > I put in the values for a existing domain, the line looked like: vhost_root="/var/domains/example.com/var/www/wiki" (I hope I undertood you right with that) Now the update would succeed, but I want to manage more than just one site on one domain :-)
I'm also trying to use webapp-config with that option and get the same issue with other vhost packages. This is quite annoying. Here's what the output of e.g. PHPMyAdmin is: >>> Emerging (1 of 1) dev-db/phpmyadmin-3.5.0 * phpMyAdmin-3.5.0-all-languages.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * Fatal error: * Fatal error: There is a problem with your configuration file. * Fatal error: webapp-config tried to read the variable "vhost_root" * Fatal error: and received the following error: * Fatal error: * Fatal error: Bad value substitution: * Fatal error: section: [USER] * Fatal error: option : vhost_root * Fatal error: key : vhost_subdomain_2 * Fatal error: rawval : .${vhost_subdomain_1}/${vhost_subdomain_3} * Fatal error: * Fatal error: Please note that webapp-config is not written in bash anymore * Fatal error: and that you cannot use the bash scripting features. * Fatal error(s) - aborting * ERROR: dev-db/phpmyadmin-3.5.0 failed (setup phase): * Could not read settings from webapp-config! * * Call stack: * ebuild.sh, line 85: Called pkg_setup * phpmyadmin-3.5.0.ebuild, line 38: Called webapp_pkg_setup * webapp.eclass, line 392: Called webapp_read_config * webapp.eclass, line 60: Called die * The specific snippet of code: * ENVVAR=$(${WEBAPP_CONFIG} --query ${PN} ${PVR}) || die "Could not read settings from webapp-config!" * * If you need support, post the output of 'emerge --info =dev-db/phpmyadmin-3.5.0', * the complete build log and the output of 'emerge -pqv =dev-db/phpmyadmin-3.5.0'. * The complete build log is located at '/var/tmp/portage/dev-db/phpmyadmin-3.5.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-db/phpmyadmin-3.5.0/temp/die.env'. * S: '/var/tmp/portage/dev-db/phpmyadmin-3.5.0/work/phpMyAdmin-3.5.0-all-languages'
(In reply to Matija "hook" Šuklje from comment #4) > I'm also trying to use webapp-config with that option and get the same issue > with other vhost packages. > > This is quite annoying. > > Here's what the output of e.g. PHPMyAdmin is: > > >>> Emerging (1 of 1) dev-db/phpmyadmin-3.5.0 > * phpMyAdmin-3.5.0-all-languages.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... > [ ok ] > * Fatal error: > * Fatal error: There is a problem with your configuration file. > * Fatal error: webapp-config tried to read the variable "vhost_root" > * Fatal error: and received the following error: > * Fatal error: > * Fatal error: Bad value substitution: > * Fatal error: section: [USER] > * Fatal error: option : vhost_root > * Fatal error: key : vhost_subdomain_2 > * Fatal error: rawval : .${vhost_subdomain_1}/${vhost_subdomain_3} > * Fatal error: > * Fatal error: Please note that webapp-config is not written in bash anymore > * Fatal error: and that you cannot use the bash scripting features. > * Fatal error(s) - aborting > * ERROR: dev-db/phpmyadmin-3.5.0 failed (setup phase): > * Could not read settings from webapp-config! > * > * Call stack: > * ebuild.sh, line 85: Called pkg_setup > * phpmyadmin-3.5.0.ebuild, line 38: Called webapp_pkg_setup > * webapp.eclass, line 392: Called webapp_read_config > * webapp.eclass, line 60: Called die > * The specific snippet of code: > * ENVVAR=$(${WEBAPP_CONFIG} --query ${PN} ${PVR}) || die > "Could not read settings from webapp-config!" > * > * If you need support, post the output of 'emerge --info > =dev-db/phpmyadmin-3.5.0', > * the complete build log and the output of 'emerge -pqv > =dev-db/phpmyadmin-3.5.0'. > * The complete build log is located at > '/var/tmp/portage/dev-db/phpmyadmin-3.5.0/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/dev-db/phpmyadmin-3.5.0/temp/die.env'. > * S: > '/var/tmp/portage/dev-db/phpmyadmin-3.5.0/work/phpMyAdmin-3.5.0-all- > languages' So I just want to verify. The reason this is failing is because you are setting vhost_root to /var/www/${vhost_subdomain_2}.${vhost_subdomain_1}/${vhost_subdomain_3} I think the problem is that you're using the variable vhost_subdomain_1. If you try using a different numbered vhost_subdomain. For instance: vhost_subdomain2="foo" vhost_subdomain3="com" vhost_subdomain4="bar" then set vhost_root="/var/www/${vhost_subdomain_2}.${vhost_subdomain_3}/${vhost_subdomain_4}" and try and and reinstall. This works correctly for me when I set them accordingly without errors.
(In reply to Devan Franchini from comment #5) > vhost_subdomain2="foo" > vhost_subdomain3="com" > vhost_subdomain4="bar" > > then set > vhost_root="/var/www/${vhost_subdomain_2}.${vhost_subdomain_3}/ > ${vhost_subdomain_4}" vhost_subdomain_2="foo" vhost_subdomain_3="com" vhost_subdomain_4="bar" Use these variables.
Created attachment 350606 [details, diff] Prevents rewritting of vhost_subdomain_# variables in /etc/vhosts/webapp-config. This patch has been created to check to see if vhost_subdomain_# exists in the config file of /etc/vhosts/webapp-config before overwriting it with the split value of vhost_hostname, which is separated by the "." delimiter. This patch should fix the issue presented in bug 349491 as well as bug 300250.
Created attachment 351604 [details, diff] Prevents rewritting of vhost_subdomain_# variables in /etc/vhosts/webapp-config. Commit message cleanup.
(In reply to Devan Franchini from comment #7) > Created attachment 350606 [details, diff] [details, diff] > Prevents rewritting of vhost_subdomain_# variables in > /etc/vhosts/webapp-config. > > This patch has been created to check to see if vhost_subdomain_# exists in > the config file of /etc/vhosts/webapp-config before overwriting it with the > split value of vhost_hostname, which is separated by the "." delimiter. This > patch should fix the issue presented in bug 349491 as well as bug 300250. This patch implements an issue though, it will first check for vhost_subdomain_1 and will warn you that it doesn't exist. This isn't something that will affect your system but the best way to fix this would be to either set vhost_subdomain_1 = "${vhostname}" or just set it as any other variable of your choice. I will talk with blueness to see if we should by default set vhost_subdomain_1 to a value or not.
*** Bug 300250 has been marked as a duplicate of this bug. ***
(In reply to Devan Franchini from comment #9) > (In reply to Devan Franchini from comment #7) > > Created attachment 350606 [details, diff] [details, diff] [details, diff] > > Prevents rewritting of vhost_subdomain_# variables in > > /etc/vhosts/webapp-config. > > > > This patch has been created to check to see if vhost_subdomain_# exists in > > the config file of /etc/vhosts/webapp-config before overwriting it with the > > split value of vhost_hostname, which is separated by the "." delimiter. This > > patch should fix the issue presented in bug 349491 as well as bug 300250. > > This patch implements an issue though, it will first check for > vhost_subdomain_1 and will warn you that it doesn't exist. This isn't > something that will affect your system but the best way to fix this would be > to either set vhost_subdomain_1 = "${vhostname}" or just set it as any other > variable of your choice. I will talk with blueness to see if we should by > default set vhost_subdomain_1 to a value or not. not sure what needs to be decided here.
(In reply to Anthony Basile from comment #11) > > not sure what needs to be decided here. Did we decide what we wanted to do here?
(In reply to Devan Franchini from comment #12) > (In reply to Anthony Basile from comment #11) > > > > not sure what needs to be decided here. > Did we decide what we wanted to do here? the best way to fix this would be to either set vhost_subdomain_1 = "${vhostname}" You can add new features as long as it doesn't break bacwards compat. So go ahead with this for the next release.
(In reply to Anthony Basile from comment #13) > (In reply to Devan Franchini from comment #12) > > (In reply to Anthony Basile from comment #11) > > > > > > not sure what needs to be decided here. > > Did we decide what we wanted to do here? > > the best way to fix this would be to either set vhost_subdomain_1 = > "${vhostname}" > > You can add new features as long as it doesn't break bacwards compat. So go > ahead with this for the next release. In order to do this we need to set a default value for vhost_subdomain_1 in the config file in /etc/vhosts/webapp-config, just to make what I was saying in the previous message a little more clear. I just want to confirm that. Should we still do this? If not, I'll try and find some other solution.
(In reply to Devan Franchini from comment #14) > (In reply to Anthony Basile from comment #13) > > (In reply to Devan Franchini from comment #12) > > > (In reply to Anthony Basile from comment #11) > > > > > > > > not sure what needs to be decided here. > > > Did we decide what we wanted to do here? > > > > the best way to fix this would be to either set vhost_subdomain_1 = > > "${vhostname}" > > > > You can add new features as long as it doesn't break bacwards compat. So go > > ahead with this for the next release. > > In order to do this we need to set a default value for vhost_subdomain_1 in > the config file in /etc/vhosts/webapp-config, just to make what I was saying > in the previous message a little more clear. I just want to confirm that. > Should we still do this? If not, I'll try and find some other solution. yeah why not. going forward we'll have this new feature as long as it doesn't *need* vhost_subdomain_1 in the config file, but its optional, then we'll retain backwards compatibility with people who just keep their old config.
(In reply to Anthony Basile from comment #15) > (In reply to Devan Franchini from comment #14) > > (In reply to Anthony Basile from comment #13) > > > (In reply to Devan Franchini from comment #12) > > > > (In reply to Anthony Basile from comment #11) > > > > > > > > > > not sure what needs to be decided here. > > > > Did we decide what we wanted to do here? > > > > > > the best way to fix this would be to either set vhost_subdomain_1 = > > > "${vhostname}" > > > > > > You can add new features as long as it doesn't break bacwards compat. So go > > > ahead with this for the next release. > > > > In order to do this we need to set a default value for vhost_subdomain_1 in > > the config file in /etc/vhosts/webapp-config, just to make what I was saying > > in the previous message a little more clear. I just want to confirm that. > > Should we still do this? If not, I'll try and find some other solution. > > yeah why not. going forward we'll have this new feature as long as it > doesn't *need* vhost_subdomain_1 in the config file, but its optional, then > we'll retain backwards compatibility with people who just keep their old > config. Yeah, webapp-config won't NEED vhost_subdomain_1 set, but it'll warn users if it's not: * * There is a problem with your configuration file or an environment variable. * webapp-config tried to read the variable "vhost_subdomain_1" * and received the following error: * * No option 'vhost_subdomain_1' in section: 'USER' This is what happens with the patch applied and you try and install/uninstall a webapp. It's not necessary to add vhost_subdomain_1 but it will at least let users know it doesn't exist. I mean, I could always try and default vhost_subdomain_1 directly in the code if it isn't found. I'll try that first before we go ahead and change the default config file.
Actually, let me scratch that, that's exactly what the code does. Duh, well. I guess I can change the config file.
(In reply to Devan Franchini from comment #17) > Actually, let me scratch that, that's exactly what the code does. Duh, well. > I guess I can change the config file. I'm conflicted. On one hand I can default vhost_subdomain_1 to vhost_hostname but that doesn't really solve the issue. For example: The split_hostname() function in config.py splits the hostname on a "." based delimiter. So if we did this in /etc/vhosts/webapp-config: vhost_hostname="foo.bar.com" If would attempt to set the vhost_subdomains variables to this: vhost_subdomain_1="foo" vhost_subdomain_2="bar" vhost_subdomain_3="com" This makes sense for the function, but if users are just trying to hard set the vhost_subdomains anyways I see no point in this feature. BUT, we don't know if every user does it this way or the split method. A quick fix for the warning though might just be to have webapp-config's get() method ignore a vhost_subdomain's nonexistence and not warn the users since we're going to overwrite it anyways with whatever is in the contents of vhost_hostname with a "." delimiter. What's your take on this? I think having the get() method not warn users might be the best solution but I feel hesitant having a function mask some kind of warning, even if we're only using the get() method to check for vhost_subdomain_# once in the entire codebase of webapp-config. I'm leaving more towards masking the warning though.
(In reply to Devan Franchini from comment #18) > (In reply to Devan Franchini from comment #17) > > Actually, let me scratch that, that's exactly what the code does. Duh, well. > > I guess I can change the config file. > > I'm conflicted. On one hand I can default vhost_subdomain_1 to > vhost_hostname but that doesn't really solve the issue. > > For example: > > The split_hostname() function in config.py splits the hostname on a "." > based delimiter. > > So if we did this in /etc/vhosts/webapp-config: > > vhost_hostname="foo.bar.com" > > If would attempt to set the vhost_subdomains variables to this: > > vhost_subdomain_1="foo" > vhost_subdomain_2="bar" > vhost_subdomain_3="com" > > This makes sense for the function, but if users are just trying to hard set > the vhost_subdomains anyways I see no point in this feature. BUT, we don't > know if every user does it this way or the split method. > > A quick fix for the warning though might just be to have webapp-config's > get() method ignore a vhost_subdomain's nonexistence and not warn the users > since we're going to overwrite it anyways with whatever is in the contents > of vhost_hostname with a "." delimiter. > > What's your take on this? I think having the get() method not warn users > might be the best solution but I feel hesitant having a function mask some > kind of warning, even if we're only using the get() method to check for > vhost_subdomain_# once in the entire codebase of webapp-config. I'm leaving > more towards masking the warning though. Also, as I forgot to mention...the reason setting vhost_subdomain_1 to vhost_hostname isn't the best solution is because if a users does have the split() method then they would get a warning for however many vhost_subdomain_# there are.
I went ahead and committed it to the experimental branch. I think it should be fine, I explained in my commit message why I believe so: http://git.overlays.gentoo.org/gitweb/?p=proj/webapp-config.git;a=commit;h=a9cfa36cae677826fe1fc1bca82a3a603d85ad91
