- /etc/heyu/x10.conf not found or not readable! (or similar depending on x10.conf file location)
First make sure permission's for the file are in fact correct, either by setting the file owner/group to the webserver's user/group or by giving read/write permission's to all. If problem persists edit your php.ini file and make sure 'open_basedir' is disabled or that the /etc/heyu directory is included.
- Warning: Cannot modify header information - headers already sent
Edit you php.ini file (usually located within apache configuration dir) locate "output_buffering" and make sure it is set to "on".
- HEYU: Can't open TTY line. check permissions!
Check apache/webserver user has permissions to use tty port chmod o+rw /dev/tts/0 (for slackware ttyS0 port)
- When veiwing the home screen, all of my modules show in the 'unknown' location.
You have a new instance of domus.Link and will need to assign the aliases to a loaction in the admin/alias screen. This is done by editing an alias and in the location drop down, typing in a new location as this field is editable.
- Error in saving config file, file has been modified.
This occurs when another user or a manual edit has occured on a config filewhen you have tried to save a modification. In most instances the changes will be detected before this happens. If it does happen, exit your browser completely and try again.
- Parse error: syntax error, unexpected T_OBJECT_OPERATOR in.....
Domus.Link now requires PHP5+ as we use the php object model with multiple object operator redirection. This is not supported in the PHP4 object model. Please upgrade to PHP5.
- Path to favicon.ico not found.
Domus.Link now requires PHP5+. OR Your DocumentRoot is not set properly in your webserver config.
- Issue starting and stopping heyu within domus.Link or through the command line after a good configuration.
Here some background information for domus.Link and heyu start/stop:
Linux/Unix specific definition: the owner of a running process is the one that can control it directly. Otherwise, permissions in linux/unix need to be granted. Root mostly has control over all, but running as root is always not recommended.
domus.Link specific definition: domus.Link requires both the heyu relay and engine to be running to function. By default, if the engine is not running and the relay is, domus will try to start it. If neither are running, it will try to start both. This is when the 'start' button is selected.
heyu specific definition: in the x10.conf file, there is a parameter to auto start the heyu engine. If this is 'start_engine AUTO', when heyu is started it will bring up both the relay and the engine. Otherwise, just the relay is started.
apache specific definition: in most linux/unix systems, the webserver is run under a specific user id such as 'apache'. This is not a root level id and has access only to the items given permission by the user creation. This would be similar to a normal user in the system.
So, if user 'brad' starts heyu and the x10.conf file does not have AUTO for start_engine, there will be one process owned by 'brad' called 'heyu_relay'.
Then the apache webserver starts under user id 'apache'. A user loads the domus.Link page and it says that hey is not running. The user selects the 'start' from the web page, and then it comes back saying heyu is still not running.
Problem: Since 'brad' started heyu_relay and apache wants to start the 'heyu_engine' the heyu relay denies another process owner to start the second process as they both have to be the same owner, which in this case is 'brad'.
So, if user 'brad' starts heyu and the x10.conf file does have AUTO for start_engine, there will be two process owned by 'brad' called 'heyu_relay and 'heyu_engine'.
Then the apache webserver starts under user id 'apache'. A user loads the domus.Link page and it says that hey is running. The user selects the 'stop' from the web page, and then it comes back saying heyu is still running.
Problem: Since 'brad' started heyu_relay and heyu engine and apache wants to stop the 'heyu_engine' and the heyu relay, the system denies another process owner to stop the second process as they both have to be the same owner, which in this case is 'brad'.
The moral of he story is, to keep control consistent for domus.Link, it is best that the heyu processes are running under the apache user id. Then domus.Link has full control.
- RESTAPI errors with "404 not found".
With version 2.0, the REST API code creates a cache that may need to be removed when upgrading. This file is in the db directory of the web install of domus.Link and is urlMap.cache. You should remove this file after upgrading or the API commands may not be properly found or are returning HTTP errors.