Almost all* of the hits that come up are either readme files, comments, or “print” statements indicating where a possible error is. None of those should have any impact on anything (to @borpin’s point).
requires the actual name of the redis service and some EmonPi specific system files.I believe there is, but it is protected by the .htaccess so it can only be accessed by localhost does this machine have a browser? Otherwise use wget or curl to get the text.
Alternatively use php -m to list all loaded modules.
The redis-server service is just that, a service that starts Redis. Redis is still Redis once it is running. When running, Redis listens on a dedicated port for Redis commands, much like mysql listens for SQL syntax. When you use php-redis from emoncms, it communicates with the Redis server via Redis syntax via that port, not via the service unit, that could be called anything.
My questions about the service name was to try and establish if it was the right Redis, the fact the service name was different might have been significant. Certainly if there was also a redis-server service and that wasn’t running that certainly would have been significant.
Other than cause unhelpful confusion, I believe there is no harm in the name being different. The main thing is ensuring there is a Redis server installed, not a Redis client. In Debian, it is normal for xxx-server and xxx-client packages (and services) to be named as such to know which it is and thus avoid discussion such as this.
I have assumed this far that there is a Redis server installed (regardless of package name), I do not know if the Ping Pong test is conclusive, but i believe the words “redis-server” did appear in the redis@default service status output (sorry, typing on mobile keypad so browsing back whilst typing isn’t easy).
The only place the naming may be an issue in emoncms is in the admin page info reports, as that does report the status of the “redis-server” by name, but that’s just a small part that will not prevent emoncms working.
I have just looked up the Redis package on openSUSE and that is apparently version 4.0.11(openSUSE Software) We are still using 3.2.6 (Debian -- Details of package redis-server in stretch). Again no idea if that’s significant, is there any way to rollback in openSUSE, I presume not. Are you using a cutting edge version of openSUSE? The versions are more in line with Debian Buster, the next and as yet unreleased version of Debian.
There is and it didn’t show redis anywhere, which left me puzzled for a minute but then I figured it out:
$ systemctl reload apache2
and now it all works 
Or at least it starts. It gives me a login screen and after I complete the form it says:
404 Not Found: Is modrewrite
configured on your system?
To which the answer is yes, and its listed in the web-based phpinfo.
I gave my redis-server version earlier. It is 4.0.10. phpredis is 4.0.1
[edit] I’m using Leap 15.0, which is the stable version of openSUSE.
The lines that appear to me to depend on the name are:
./.travis.yml: - sudo apt-get install php-pear php$TRAVIS_PHP_VERSION-dev redis-server build-essential g++ wget -y
./Modules/admin/admin_main_view.php: $services['redis-server'] = getServiceStatus('redis-server.service');
./scripts/logger/rc.local:for i in "emoncms.log" "mysql.log" "redis/redis-server.log" "mysql/error.log" ; do touch /var/log/"$i"; done
./scripts/logger/rc.local:for i in "emoncms.log" "mysql.log" "redis/redis-server.log" "mysql/error.log" "apache2" ; do ""chmod 666"" /var/log/"$i"; done
./scripts/logger/rc.local:/etc/init.d/redis-server restart
./scripts/mqtt_input.service:After=mosquitto.service mysql.service redis-server.service
./scripts/services/emoncms_mqtt/emoncms_mqtt.service:Wants=mosquitto.service mysql.service redis-server.service
./scripts/services/emoncms_mqtt/emoncms_mqtt.service:After=mosquitto.service mysql.service redis-server.service
./scripts/services/feedwriter/feedwriter.service:Wants=mysql.service redis-server.service
./scripts/services/feedwriter/feedwriter.service:After=mysql.service redis-server.service
./scripts/services/service-runner/service-runner.service:Wants=redis-server.service
./scripts/services/service-runner/service-runner.service:After=redis-server.service
I think you need to restart apache2 after enabling mod_rewrite, not just a reload.
[Edit] also depending on how you have set up your virtual host, you’ll possibly need a AllowOverride All rule in there somewhere.
I believe reload is equivalent to a graceful restart. That’s what the log says:
AH00171: Graceful restart requested, doing restart
It certainly made redis available, so I’m not sure why the login is failing now. There’s nothing in the apache log and emoncms.log is empty.
[edit] There’s no virtual host. It’s the default server.
[edit2] I didn’t need to enable mod_rewrite; it’s always been enabled and it shows in phpinfo
All of those .service files and the rc.local file relate to external services that cannot use “variable” names - they are not part of the emonCMS website so have nothing to do with any of your issues (as you already know by now anyway)
The Travis file is related to auto build testing on GitHub, also unrelated to the emonCMS website.
The only file that is part of the emonCMS website is the admin_main_view.php and that is the “service checker” as per @pb66’s message above that will show an incorrect “service status” for redis-server on the admin page but otherwise has no impact on the use of redis.
The default virtual host rules will be defined in apache2.conf then perhaps?
It was the norm for that file to be edited to allow rewrites server wide, but that is frowned upon and should be overridden with a virtual host.
Again, no idea about openSUSE but the preferred way with Debian etc is to create a new emoncms.conf virtual host and then disable the 000-default.conf site and enable the emoncms.conf site instead with the rules required for emoncms. You could look at the docs in the emoncms repo for pointers.
[Edit] I would still try restarting apache2 before delving in too deep, just in case, even if just to rule it out.
Again, I am using the default server configured as in “default-server.conf . . . . . . . . . set up the default server that replies to non-virtual-host requests”. There are NO virtual hosts.
I already said and posted the log entry that a reload does a graceful restart.
[edit] I think the problem may be that you have a bunch of rules in a .htaccess file. openSUSE doesn’t generally use .htaccess files (I don’t remember why, I think it’s something to do with security risks). Instead it uses specific conf files in /etc/apache2/conf.d/ so I’ll see how easy it is to copy the .htaccess to that directory and/or perhaps make an exception to the standard rule that forbids them for the emoncms directory.
[edit2] OK so I copied the .htaccess to /etc/apache2/conf.d/emoncms and restarted apache.
First problem - you have obsolete directives at the end of the file Order, Deny and Allow have been replaced by Require:
# protect phpinfo, only allow localhost and local network access
<Files php-info.php>
# djh replace obsolete Order etc directives with Require
# Order Deny,Allow
# Deny from all
# Allow from 10
# Allow from 172
# Allow from 192
Require ip 10 172 192.168
</Files>
I also wrapped a
<Directory /srv/www/htdocs/emoncms>
around everything but now I’m getting - second problem -
# Access forbidden!
You don't have permission to access the requested directory. There is either no index document or the directory is read-protected.
Error 403
I’m stopping for lunch, so if anybody has any ideas I’d love to hear them 
[edit3] I’ve now had lunch and added a FollowSymLinks option to the apache conf file and that’s got around the 403 error. Now I see:
Username does not exist
when I try to login. How and where does emoncms store its usernames and passwords? google isn’t helping so far.
I’d certainly be rebooting the whole thing. I know the theory says you don’t need to, but IME you often do.
There’s absolutely no way I would consider rebooting the machine, if that’s what you mean.
But anyway, I’m past the apache problems now. If you look at the last part of my message above, you can see the current state. I suspect emoncms can’t access its database. Looking at the emoncms user in the mysql (actually mariadb) database, it doesn’t seem to have any permissions. I’ll check what and how it’s supposed to have if I can find the instructions again.
OK, so I found the appropriate table in the emoncms database and its empty. Which is what made me think emoncms couldn’t access the database, but I found its privileges in the db table so that’s OK. So then I thought maybe the database is empty because I’ve never registered? So I decided to register instead of login. When I did I got this error:
Fatal error: Uncaught Error: Call to undefined function ctype_alnum() in /srv/www/htdocs/emoncms/Modules/user/user_model.php:229
Stack trace:
#0 /srv/www/htdocs/emoncms/Modules/user/user_controller.php(51): User->register('dhoworth', 'password', 'my-opensuse-emo...')
#1 /srv/www/htdocs/emoncms/core.php(64): user_controller()
#2 /srv/www/htdocs/emoncms/index.php(210): controller('user')
#3 {main} thrown in /srv/www/htdocs/emoncms/Modules/user/user_model.php on line 229
Does anybody recognize these symptoms before I go crawling through yet more code?
[edit] PS I just created issue 1220 for the obsolete directives in the htaccess file.
They don’t have anything to do with my getting to the point of being able to log in, no. But they will affect how the system works, I believe. For example, feedwriter should be run. So they will cause me problems.
And you can pass variables to systemd unit files, using environment variables. So there’s no reason for writing code with hardwired names that can change from system to system. Doing so simply breaks portability. Denying it’s a problem is head-in-the-sand AFAICT.
It is expected that if you’re doing a self install, you know enough to fix that stuff. To be fair to the EmonCMS folks, as far as I’m aware you are the first person to ever find a redis service NOT called redis-server and there’s people using a few different distro’s with self installs.
If you have a better idea on how it should be treated that works better in all cases and is more easily supported, fix it and submit a PR on GitHub.
So nobody answered so I went digging. Apparently ctype is an extension and openSUSE packs extensions separately. Now I’ve installed that, I can login. Again, IMHO, best practice is to check dependencies at install time and report them.
@djh, did you discover the solution to your Redis problem? I am guessing you did but cannot see what it was here (if you can remember).
I don’t remember I’m afraid. I gave up on the whole idea of trying to run OEM stuff on openSUSE unless/until we get an install/configuration system that can deal with the differences. I’ve kind of lost touch with that effort but AFAIK it doesn’t exist yet.