Posted on Leave a comment

PROVISIO – Support Request: Sitekiosk will not automatically run under restricted account

But when changing the password of the SiteKiosk user account without using the System-Security-Manager SiteKiosk it can ot work anymore as the SiteKiosk software doesn’t know the new password.
Usually you just have to reset the password of the SiteKiosk user was reset to
again. Then you should make sure that no other process “systemsecurity.exe” is running before starting the System-Security-Manager again (Task Manager).
Alternatively you can restart the system.

If this doesn’t work you might reinstall the SiteKiosk user account.
– Delete the SiteKiosk user in the Windows environment (–>Control Panel–>User Accounts)
– Open the command line (cmd.exe) and switch to the SiteKiosk Program Files directory (usually “C:\Program Files\SiteKiosk“).
– Enter the command “systemsecurity.exe /uninstall”
– When done, enter the command “systemsecurity.exe /install”
– Exit the command console and check the Windows user environment (–>Control Panel–>User Accounts) to see if the SiteKiosk user is present again.
– Launch the System Security Wizard and set it to “protected.”
This ensures that the default settings of the SiteKiosk user will be restored.

Source: PROVISIO – Support Request: Sitekiosk will not automatically run under restricted account

Posted on Leave a comment

Web Browser Asset – Intuiface

Known limitations

On Windows PCs

  • Certain Websites such as “Matterport” cannot be manipulated using a Mouse. Such websites should correctly respond to touch manipulation. Fixed with the release of Intuiface 6.3.5
  • The Web Browser asset will not be rendered correctly when using Remote Desktop Sessions.
  • PDF documents rendered in the Web Browser can be scrolled with a mouse, but not with touch.
  • Links within a PDF in the Web Browser can be opened with a mouse, but not with touch.
  • If your Composer or Player for Windows is running on Windows 7, make sure you installed all the latest Windows 7 updates to avoid some web engine errors.
  • Other than Flash, all plugin-based content such as Java, Microsoft Silverlight, ActiveX, PDF, Webcam, geolocation & notifications are not supported.
  • If the Web Browser asset is somewhere on a multi-screen display other than Screen 1, dropdown lists will not respond to touch events. A mouse would have to be used.
  • Virtual keyboard input is not possible within Flash animation (e.g. Flash-based forms will not work)
  • The “Open URL” action requires the entered URL to be preceded by http:// or https://
  • No support for proxies or htaccess authentication
  • To permit use of a responsively designed website, the first <html> or <head> tag of the webpage should not contain any attribute. For example, if your webpage contains tags such as : <html lang=en>, the CSS media queries will be ignored and responsive capabilities will not work. This snippet of HTML illustrates the correct approach:
    <!DOCTYPE html> <html> <head> <title>My title</title> …
  • To adjust the size of a responsive webpage, use the “Webpage width” property of the Web Browser asset, not the handle of the container in Composer’s edit window. Only by changing the resolution, via the “Webpage width” property, will you trigger a responsive adjustment of the webpage layout.
  • Some interactive web components such as Matterport may not work properly when using a mouse while interacting using a touch screen will work properly.
  • If playing, sounds of video or audio content will continue to be heard after closing or hiding the Web Browser asset.
  • Zoom level property is shared between multiple Web Browsers in the same scene (even if the Zoom values are different).
  • The Virtual Keyboard may be displayed for a brief second when loading web pages that contain text input or input forms.


Source: Web Browser Asset – Intuiface

Posted on Leave a comment

Woocommerce emails not sending! |

WooCommerce sends emails with the wp_mail() WordPress function. WordPress in turn calls on PHP to send the email, and PHP calls on the server at your host. If you install an SMTP plugin, the request will no longer go to your host email server which is causing your notification errors, but will go to your SMTP plugin and added to a queue to be sent out.

Source: Woocommerce emails not sending! |

Posted on Leave a comment

Logging – Dovecot Wiki

Dovecot Logging

Dovecot always logs a detailed error message if something goes wrong. If it doesn’t, it’s considered a bug and will be fixed. However almost always the problem is that you’re looking at the wrong log file; error messages may be logged to a different file than informational messages. By default Dovecot logs to syslog using mail facility. You can change the facility from syslog_facility setting. You can also configure Dovecot to write to log files directly, see below.

When using syslog, Dovecot uses 4 different logging levels:

  • info: Informational and debug messages.

  • warning: Warnings that don’t cause an actual error, but are useful to know about.

  • err: Non-fatal errors.

  • crit: Fatal errors that cause the process to die.

Where exactly these messages are logged depends entirely on your syslog configuration. Often everything is logged to /var/log/mail.log or /var/log/maillog, and err and crit are logged to /var/log/mail.err. This is not necessarily true for your configuration though.

You can find the correct log files using these methods:

  • Info log: After starting Dovecot, grep "starting up" /var/log/*. It should show a line such as: Dovecot v1.0.0 starting up

  • Error logs: Use dovecot --log-error command, which makes Dovecot log a few messages and exit. Then grep "This is Dovecot's" /var/log/* to find them. You should see:

    • With Dovecot v1.0.0 you’ll find only the crit log: This is Dovecot's error log

    • With Dovecot v1.0.1+ you’ll find all of them:
      • warningThis is Dovecot's warning log

      • errThis is Dovecot's error log

      • critThis is Dovecot's fatal log

  • You can also check your /etc/syslog.conf to see how it’s configured.

Internal Errors

If IMAP or POP3 processes encounter some error, they don’t show the exact reason for clients. Instead they show:

Internal error occurred. Refer to server log for more information. [2006-01-07 22:35:11]

The point is that whenever anything unexpected happens, Dovecot doesn’t leak any extra information about it to clients. They don’t need it and they might try to exploit it in some ways, so the less they know the better.

The real error message is written to the error log file. The timestamp is meant for you to help you find it.

Changing Log File Paths

If you don’t want to use syslog, or if you just can’t find the Dovecot’s error logs, you can make Dovecot log elsewhere as well:

log_path = /var/log/dovecot.log
# If you want everything in one file, just don't specify info_log_path
info_log_path = /var/log/dovecot-info.log

The warning and error messages will go to file specified by log_path, while everything else goes to info_log_path. If you do this, make sure you’re really looking at the log_path file for error messages, since the “Starting up” message is written to info_log_path file.

Rotating Logs

If you change from syslog to an external log file, you can use logrotate (available on most recent linux distros) to maintain the Dovecot logfile so it doesn’t grow beyond a manageable size. Save the below scriptlet as /etc/logrotate.d/dovecot:

# dovecot SIGUSR1: Re-opens the log files.
/var/log/dovecot*.log {
    /bin/kill -USR1 `cat /var/run/dovecot/ 2>/dev/null` 2> /dev/null || true

NOTE: change the path to the logfile(s) and the file as appropriate for your system configuration. The default location of is /usr/local/var/run/dovecot/

Logging verbosity

There are several settings that control logging verbosity. By default they’re all disabled, but they may be useful for debugging.

  • auth_verbose=yes enables logging all failed authentication attempts.

  • auth_debug=yes enables all authentication debug logging (also enables auth_verbose). Passwords are logged as <hidden>.

  • auth_debug_passwords=yes does everything that auth_debug=yes does, but it also removes password hiding.

  • mail_debug=yes enables all kinds of mail related debug logging, such as showing where Dovecot is looking for mails.

  • verbose_ssl=yes enables logging SSL errors and warnings. Even without this setting if connection is closed because of an SSL error, the error is logged as the disconnection reason (v1.1+).

Source: Logging – Dovecot Wiki