Wix install location appearing incorrectly as command line argument - directory

I'm attempting to create an installer with wix, and I want it to behave in such a way that when the short cut is selected, it passes the install file to my programs args[], for it to use a path to execute a file.
However, I have added a few logs, and noticed that for some reason the path it is receiving is "C:\Program". I cannot get this to appear differently, even if I manually set the arguments to be the full path. Here's some snippets of the .wxs file.
<!-- Define directory structure -->
<Directory Id ="TARGETDIR" Name ="SourceDir">
<Directory Id ="ProgramFilesFolder">
<Directory Id ="MyAppsFolder" Name ="Applications">
<Directory Id ="INSTALLFOLDER" Name ="MyApp">
</Directory>
<Directory Id ="ProgramMenuFolder">
<Directory Id ="ApplicationProgramsFolder" Name="Example Folder">
<Directory Id ="ShortcutFolder" Name ="MyApp">
</Directory>
</Directory>
</Directory>
</Directory>
</Directory>
</Directory>
<!-- Creating the shortcut -->
<DirectoryRef Id ="ShortcutFolder">
<Component Id ="ApplicationShortcut" Guid="{GUID_HERE}">
<Shortcut Id ="RunMyApp"
Name ="MyApp"
Description ="Runs MyApp"
Target ="[INSTALLFOLDER]MyApp.exe"
WorkingDirectory ="INSTALLFOLDER"
Icon ="MyApp.ico"
Arguments ="[INSTALLFOLDER]FileToLoad.xml"/>
The [INSTALLFOLDER] seems to work for everything else but this last line in the arguments.
Thanks in advance

It's a well-known behavior, WiX doesn't know what your arguments are then it doesn't quote them. Note that [INSTALLFOLDER] will be expanded during installation to (for example) c:\program files\your app, it's like you execute your application from command line with this syntax:
MyApp c:\program files\your app
Note that your application will have { "c:\\program", "files\\your", "app" }.
Just quote your path explicitly:
<Shortcut Id ="RunMyApp"
Name ="MyApp"
Description ="Runs MyApp"
Target ="[INSTALLFOLDER]MyApp.exe"
WorkingDirectory ="INSTALLFOLDER"
Icon ="MyApp.ico"
Arguments =""[INSTALLFOLDER]FileToLoad.xml""/>
It'll result in "c:\program files\your app\FileToLoad.xml" and command line parser will recognize it as a single argument. Note " character entity reference, for a complete list you may refer to List of XML and HTML character entity references.

I've found that by remove the [INSTALLFOLDER], it worked just fine. The line now looks like this:
Arguments ="[INSTALLFOLDER]FileToLoad.xml"/>
I have noticed it may be because the working directory is already set to INSTALLFOLDER, although I'm not sure.

Related

OpenStack Dashboard Login page does not load

I installed OpenStack Dashboard following Installation Guide here:
https://docs.openstack.org/horizon/wallaby/install/install-rdo.html
Not very compicated but Dashboad does not work. After the first access, there was only "Forbidden"
status for url http://localhost/dashboard/. Then I investigated /etc/httpd/conf.d/openstack-dashboard.conf file (it's content below) and noticed that the whole wsgi directory missing on the system. I tried to correct WSGISriptAlias to some another location in /usr/share/openstack-dashboard directory structure (for example, I tried with /usr/share/openstack-dashboard/openstack_dashboard/wsgi.py) but it then status was Not Found and URL was redirected to http://localhost/auth/login/?next=/dashboard/.
I am not very familiar with web development so I don't completely understand what it means but after that I tried to find some solution on internet and I found this on Ask OpenStack:
https://ask.openstack.org/en/question/13952/horizon-apache-launch-error/
I tried with that solution but neither this helped me, after configuring the server according to that page, nothing appears on the page, only "Not Found". Please can someone help me to find some solution for this problem?
Thanks.
Here is content of the original /etc/httpd/conf.d/openstack-dashboard.conf file:
WSGIDaemonProcess dashboard
WSGIProcessGroup dashboard
WSGISocketPrefix run/wsgi
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /dashboard /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi
Alias /dashboard/static /usr/share/openstack-dashboard/static
<Directory /usr/share/openstack-dashboard/openstack_dashboard/wsgi>
Options All
AllowOverride All
Require all granted
allow from all
</Directory>
<Directory /usr/share/openstack-dashboard/static>
Options All
AllowOverride All
Require all granted
allow from all
</Directory>
to not bother you anymore with my stupid questions,
I found solution on another place which says that I have to add WEBROOT directive to
/etc/openstack-dashboard/Local_settings which was missing.
Thanks.
Regards.

Why is my css showing ���?

System details:
Server: Apache, Ubuntu 16.02
Client: Windows 10, Chrome
My apache config file looks as follows:
<VirtualHost *:80>
ServerName mycoolsiteA.mydomain.com
ServerAlias mycoolsiteB.mydomain.com
Alias /static /var/www/python/mysite/static
Alias /templates /var/www/python/mysite/templates
WSGIDaemonProcess my_app user=www-data group=www-data threads=5
WSGIScriptAlias / /var/www/python/mysite/start.py
WSGIScriptReloading On
<Directory /var/www/python/mysite>
WSGIProcessGroup my_app
WSGIApplicationGroup %{GLOBAL}
order deny,allow
Allow from all
</Directory>
</VirtualHost>
When I load the css in a browser it is showing the following. However, this is quite random. It "sometimes" works, and sometimes does not.
My example url is this:
https://mycoolsiteA.mydomain.com/static/css/bs/bootstrap.min.css
We do have a Firewall appliance which auto-redirects http to https, but I'm loading the css directly with https.
And the result looks like this:
Yet, if I refresh several times, or add a r=number on the end, it will clear the cache and load. But, it will do it again randomly until I clear the cache again.
Here it is loaded and working:
Any thoughts, direction on where to look to fix this?
Welcome to the fun world of UTF-8!
I've seen this dozens of times in PHP (see UTF-8 all the way through). What you're experiencing is almost certainly a UTF-8 file being delivered as some other character encoding (or vice-versa). I downloaded Bootstrap and Notepad++ identifies them as ANSI encoded. Your web server might be forcing that to use UTF-8. Look at the response headers for something like this
Content-Type: text/css; charset=UTF-8
So your web server is saying it's UTF-8 but it's really not. At which point your browser starts vomiting out �, meaning it doesn't recognize the character.
There's a couple of ways to deal with this if that's the case.
Re-encode the file as UTF-8 (Notepad++ can do this for you)
Stop passing a default UTF-8. Your browser will try to identify the encoding
Just for kicks, try loading the CSS directly from the MaxCDN servers
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">
They do not pass a UTF-8 header

WordPress Comment Image plugin doesn't save uploaded image when Apache Requires are used

I've got an Apache 2.4.7 box with a WordPress 4.1 installation and a plugin added which allows users to add images to comments on pages/posts (https://wordpress.org/plugins/comment-images/). The image upload feature isn't working when Require statements are added to restrict access to the site (it's a development environment so limited access is required).
The image upload actually works with or without Require directives but when the directives are added, the reference to the uploaded image doesn't get saved to WordPress properly.
The error from the log is:
PHP Warning: preg_match_all() expects parameter 2 to be string, object given in /var/www/html/wp-content/plugins/comment-images/class-comment-image.php on line 480
I dumped the object being passed into a file (serialized):
O:8:"WP_Error":2:{s:16:"^#WP_Error^#errors";a:1:{s:8:"http_404";a:1:{i:0;s:12:"Unauthorized";}}s:20:"^#WP_Error^#error_data";a:0:{}}
I outputted the print_debug_backtrace() as well to show the calls. I've had to delete the comment data from the arrays for privacy reasons:
#0 Comment_Image->save_comment_image(63)
#1 call_user_func_array(Array ([0] => Comment_Image Object ([] => 5000000,[] => ,[] => ),[1] => save_comment_image), Array ([0] => 63)) called at [/var/www/html/wp-includes/plugin.php:496]
#2 do_action(wp_insert_comment, 63, stdClass Object ()) called at [/var/www/html/wp-includes/comment.php:1941]
#3 wp_insert_comment(Array ()) called at [/var/www/html/wp-includes/comment.php:2083]
#4 wp_new_comment(Array ()) called at [/var/www/html/wp-comments-post.php:137]
The directives for the <Directory> with the WP install in are (with IPs obfuscated):
AllowOverride All
<RequireAny>
AuthType Basic
AuthName "Restricted Access"
AuthBasicProvider file
AuthUserFile /var/www/.htpasswd
Require valid-user
Require user dev www-data
Require ip xx.xx.xx.xx/xx
Require ip xx.xx.xx.xx
Require local
</RequireAny>
If I add Require all granted (or just remove the Require directives), then the feature works as expected and uploaded images show up. Note Require local is there which as I understand it should cover everything for the local box.
Things I've checked:
Revised the configs in light of Apache 2.4 changes to auth modules and ordering importance etc.
WordPress install folder is recursively chown'ed correctly
Permissions on upload folder are 777'd, but shouldn't matter as the upload always succeeds
Where does this issue lie??
Looks like the plugin does not handle well the fact that your server is unable to download an image on itself.
The warning (class-comment-image.php on line 480) corresponds to this snippet:
$img_url = media_sideload_image( $comment_image_file['url'], $post_id );
preg_match_all( "#[^<img src='](.*)[^'alt='' />]#", $img_url, $matches );
$comment_image_file['url'] = $matches[0][0];
The WP media_sideload_image function uses curl to get the image, and because of your restrictions it does not succeed, and then returns an error object that the preg_match_all function cannot handle.
The data is saved later in the metas; it explains why the reference is not saved even if the upload worked.
Require local probably does not work on your dev server, you may try to replace it with its local address.
I tried adding Require ip <local-ip-of-box> as per johansatge's suggestion. Whilst this didn't doesn't work, it made me think..
The box is in Azure which assigns a floating public IP. Annoyingly, the cURL request was bouncing out and using that public IP - because the domain used for the box wasn't added to the hosts file.
The solution was to add <domain-of-website-on-box> to the loopback (127.0.0.1) entry in /etc/hosts.

<suffix> invalid DN 21 (Invalid syntax) openldap

Actually based on http://www.openldap.org/doc/admin24/slapdconf2.html said that i can converting slapd.conf to cn=config format.
So for this purpose i try to make slapd.conf file on server which have role provider like bellow:
database bdb
suffix dc=mydomain,dc=org
rootdn cn=admin,dc=mydomain,dc=org
directory /var/lib/ldap/db
index objectclass,entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
database config
rootpw mypassword
Then i try to convert that file using slaptest command, but i got error message like bellow :
$ slaptest -f slapd.conf -v
slapd.conf: line 2: <suffix> invalid DN 21 (Invalid syntax)
slaptest: bad configuration file
Actually my suffix is absolutely right, but why always "invalid DN"
How to solve this error ?
You probably have solved it by now, but for the benefit of the googles out there...
Your suffix is not absolutely right because it uses the domainComponent attribute "dc=" but you haven't added the schema that defines it. So until that is done the distinguished name is an unknown and "invalid DN".
Explanation: In the core.schema file (typically in /etc/openldap/schemas/, at least for RedHat/CentOS RPMs) you can find this (and much more that is needed):
# RFC 1274 + RFC 2247
attributetype ( 0.9.2342.19200300.100.1.25
NAME ( 'dc' 'domainComponent' )
DESC 'RFC1274/2247: domain component'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
What you have to do it to include this schema file to your configuration by adding this to the beginning (assuming the file is at this path, adjust as needed):
include /etc/openldap/schema/core.schema
You probably also need other schema files, but this will solve this error.
I had the same problem with too minimal of a file, I added a few extra details and it works
#slapd.conf
#schemas to use
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
#log
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
########################################
##### dbm database definitions ####
########################################
database bdb
suffix dc=server,dc=com
rootdn cn=Manager,dc=server,dc=com
rootpw secret
#database directory
directory /var/lib/ldap
#end
According to this you might only be missing the pidfile location as it changed between versions but you will eventually add the rest anyway.
well you should delete defaults files before run your test:
example on CentOS:
rm -rf /etc/openldap/slapd.d/*
and in database directory, should have a DB_CONFIG file
all archives with ldap-user-granted (chown ldap:ldap)
include this files in #schemas to use
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/dyngroup.schema

Why Apache's <Files> directive keeps giving me error 500?

This directive in .htaccess:
<Files wp-config.php>  
order allow,deny  
deny from all 
</Files>
Gives me error 500. Ave you maybe got some good idea about?
Thank you
Two possibilities jump to mind:
First, usually I see the filename quoted: <Files "wp-config.php">. I forget whether Apache requires quotes or not, so try this and see if that fixes the problem.
Second, your Apache server administrator may not have enabled the required AllowOverride permissions to allow you to do this.
In either case, checking the Apache error logs will reveal the true problem.

Resources