Closed scribas closed 4 years ago
goekay
commented
4 years ago the exception from Steve.3.3.2 is an indicator for main.properties file not being configured correctly.
i think, that the exception from Steve.3.4.0 is a different manifestation of the same underlying cause. i will add additional guards to prevent this exception, but they will not resolve your problem.
please make sure that values for fields in main.properties are correct, e.g. you are using the correct ip and port.
scribas
commented
4 years ago awesome, will have a look. does the port have to be 8080 for unencrypted and 8442 for encrypted?
goekay
commented
4 years ago no, not at all. these values depend on your specific system and network configuration.
scribas
commented
4 years ago Below is the main.properties file. I just changed the 2 usernames and passwords and the server_host to my_aws_elastic_ip for security reasons. Can you spot anything else wrong?
# Just to be backwards compatible with previous versions, this is set to "steve",
# since there might be already configured chargepoints expecting the older path.
# Otherwise, might as well be changed to something else or be left empty.
#
context.path = steve
# Database configuration
#
db.ip = localhost
db.port = 3306
db.schema = stevedb
db.user = db_user
db.password = db_password
# Credentials for Web interface access
#
auth.user = steve_user
auth.password = steve_password
# Jetty configuration
#
server.host = my_aws_elastic_ip
server.gzip.enabled = false
# Jetty HTTP configuration
#
http.enabled = true
http.port = 8080
# Jetty HTTPS configuration
#
https.enabled = false
https.port = 8443
keystore.path =
keystore.password =
# When the WebSocket/Json charge point opens more than one WebSocket connection,
# we need a mechanism/strategy to select one of them for outgoing requests.
# For allowed values see de.rwth.idsg.steve.ocpp.ws.custom.WsSessionSelectStrategyEnum.
#
ws.session.select.strategy = ALWAYS_LAST
# if BootNotification messages arrive (SOAP) or WebSocket connection attempts are made (JSON) from unknown charging
# stations, we reject these charging stations, because stations with these chargeBoxIds were NOT inserted into database
# beforehand. by setting this property to true, this behaviour can be modified to automatically insert unknown
# stations into database and accept their requests.
#
# CAUTION: setting this property to true is very dangerous, because we will accept EVERY BootNotification or WebSocket
# connection attempt from ANY sender as long as the sender knows the URL and sends a valid message.
#
auto.register.unknown.stations = false
### DO NOT MODIFY ###
steve.version = ${project.version}
git.describe = ${git.commit.id.describe}
db.sql.logging = false
profile = prodCan you spot anything else wrong?
no, but i also have no experience running java servers on aws. my instinct is that the ip you are setting is not the ip you should be using.
kalldert
commented
4 years ago Hi, I dont know if this helps or not but I just tried to install 3.4.0 on a fresh instance of Ubuntu 18.04 VM and got the exact same error on 3.4.0 as mentioned here. Rolled back my VM and used the same main.properties that I used on 3.4.0 on 3.3.2 and that works perfectly.
/Jonas
goekay
commented
4 years ago @kalldert thanks for your input. can you please test the repository with my latest commit ddd6fc0cef0209cfe10639811ff4a605ca067623 and give feedback, whether the issue is resolved. the problem seems to be caused by 72cad0be272587ea22af677eb091455f4d5617ff, which was introduced earlier.
still, since @scribas is having issues with 3.3.2 as well, the exception stacktrace indicates a wrongly used ip setting.
scribas
commented
4 years ago I tried using the public DNS of AWS, which I use to connect with SSH and SCP. Now SteVe actually launches on 3.3.2. The problem is that I then cannot access the web interface with the public DNS address it provides, nor with the elastic IP. As @goekay mentioned, this is most probably an issue with AWS specifically. 3.4.0 still throws the same problem mentioned before.
kalldert
commented
4 years ago @goekay Thanks. I installed the latest update and 3.4.0 now works.
goekay
commented
4 years ago 3.4.0 still throws the same problem mentioned before.
@scribas 3.4.0 should not throw the NullPointerException anymore. something like java.net.BindException: Cannot assign requested address is still possible, since --as i said it-- is related to your ip setting and aws setup. i cannot help there.
@kalldert this is great to hear.
scribas
commented
4 years ago @goekay i have now launched a google cloud instance, to see whether this works better. Again, if I use the public IP address that Google provided, the app cannot bind to the IP address and fails. It runs successfully, if I point Steve to the internal IP address, however, then it does not seem to be reachable (or at least, I don't know how to reach it).
Btw, I did open up the outgoing 8080 port on both the operating system and the Google cloud management interface. Same on AWS. Not sure what to try next?
goekay
commented
4 years ago @scribas it is perfectly reasonable that external/public IP is only there for clients to access it. local apps probably should bind to localhost or 127.0.0.1. now, the request routing from external ip/port to internal ip/port should be part of a configuration, how this configuration step should be done is specific to your cloud/vm provider.
csamsel
commented
4 years ago @scribas what ip configuration are you using for your cloud service? for google cloud a reserved fixed ip adress is not actually assigned to your instance (so steve can not bind to it) but via a 1:1 NAT to the ethereal instance ip. What you have to do in this case is have steve bind to 0.0.0.0
Also you have to allow traffic INCOMING (ingress) on port 8080 (or what ever you use)
scribas
commented
4 years ago @csamsel apologies - I opened the incoming ports. The outgoing ports are all open.
I tried binding steve to 0.0.0.0, but that did not help either. Do I maybe need to do something with iptables, to route the external IP to localhost?
csamsel
commented
4 years ago No, thats done by Google. You could check if the VMs firewall (if activated) is blocking anything. Should be showing up in dmesg. If it's ubuntu you could do e.g. ufw allow 8080
scribas
commented
4 years ago @csamsel I am indeed running ubuntu on both Google Cloud and AWS. I tried running centos on AWS at the beginning, but found that software versions were a bit more outdated, as they are more conservative.
I ran dmesg and read up a bit more about it. I could not see anything in particular, although, may simply not know what to look for. But at least I now know more about dmesg. Too much to learn about this linux world.
I did not know about ufw either. I rather followed some tutorials, installed firewalld and used firewall_ctrl to open up the ports.
Initially, on AWS, I did upload php and apache, and saw the default php welcome page on port 80. When I started the SteVe installation, port 80 went dead. I hope that this does not mean that I broke something towards the outside world, but suspect that this was rather jetty replacing itself with apache as the default web server? I must admit that I still don't understand the web server world well enough, to go look for the place in etc where the default web server resides, never mind how one would make both run in parallel.
goekay
commented
4 years ago guys.... so many people are running java servers on cloud providers (aws, google cloud, etc.). i cannot imagine this configuration being so hard and it requiring such intricate tinkering.
i just googled a bit and came across the following pages:
the table from "get started" page contains multiple sample projects. the sample project "java-se-jetty-gradle-v3.zip" has one java class, where only the port is set. and the port is read as system environment variable. if i remember correctly, jetty binds to 0.0.0.0 if no hostname is set. therefore, the following should work.
server.host = 0.0.0.0
http.port = $PORTnow the question is: where does the port come from? some management/configuration web ui must have this setting.
another project from the table (https://github.com/aws-samples/eb-java-scorekeep) uses localhost as server.host and 5000 as port.
csamsel
commented
4 years ago @goekay There are multiple ways of deploying things to e.g. AWS.
You absolutely can use a infrastructure as a service solution where you directly deploy the Steve application to AWS using Elastic Beanstalk and configure it to use a Amazon RDS MySQL instance as database. That would probably be the preferred way as you dont have to deal with OS updates and HA and backups come with it at no additional configuration - but it would also cost more.
@scribas just spun up a standard Ubuntu VM in AWS (probably using EC2) as you would you do in VMware vCenter and tried configuring it. Thats a bit cheaper and you are a bit more flexible w.r.t. to e.g. JDK and MySQL versions. Also costs less then using RDS.
For me personally, both variants are quiet straight forward to configure, but without AWS and Linux knowledge it isn't. But then i would recommend running any service available on the internet anyways.
@goekay The AWS Java SDK you linked is for orchestration (similar as the vCenter API) - you can configure AWS with - e.g. the Deployment units, API Gateway, Lamba configuration and such. Not really relevant here.
csamsel
commented
4 years ago I created a SteVe instance using AWS lightsail and it worked fine.
csamsel
commented
4 years ago @scribas @goekay I wrote a howto for AWS Lightsail: https://github.com/RWTH-i5-IDSG/steve/wiki/Create-SteVe-Instance-in-AWS-Lightsail
scribas
commented
4 years ago @csamsel i wanted to try out your tutorial today, but ended up running out of time. Hopefully, I will get a gap tomorrow. Thank you so much for your effort! This looks very detailed.
scribas
commented
4 years ago @csamsel, I finally managed to get it running. Very well written tutorial!
Initially, I locked myself out of ssh, because I allowed ubuntu to replace the config file with the default operating system config. May be worth adding into your wiki page, that when prompted during the apt upgrade whether config files should be replaced by default operating system files, NOT to do that. Sort of obvious in hindsight, but while following a tutorial, one does not always think things through.
Then, to really finish off the tutorial, please add right at the end, that the internal IP address must obviously be replaced by the public IP in the URL to access the management environment.
Finally, please create a link on the main page of the project to this tutorial. This is super useful for people wanting to deploy steve on AWS.
Just out of interest, do you have any idea how many professional charging companies are actually running steve to manage their infrastructure? It would be interesting to get some sort of idea, whether there are major companies using this open source project?
csamsel
commented
4 years ago Thanks for your feedback, i'll add a few remarks. But please keep in mind that these are very basic issues, that everyone working on Linux/Servers/Cloud must understand. If not, please ask someone who does.
We know a few cases of companies having SteVe running in AWS (EC2 though, not Lightsail). Most SteVe instances are probably deployed in a residential environment - as VM or an Raspberry Pi.
goekay
commented
4 years ago Just out of interest, do you have any idea how many professional charging companies are actually running steve to manage their infrastructure?
@scribas i am being contacted with questions etc. from multiple companies from all over the world all the time. however, i cannot say how big these companies are and how many stations/users they are managing.
Checklist
Specifications
Expected Behavior
When running
java -jar target/steve.jar, web server should start.Actual Behavior
For SteVe.3.4.0: Maven ran successfully and produced
target/steve.jar. When runningjava -jar target/steve.jar, I get the following error message:For Steve.3.3.2:
Log file contains:
Steps to Reproduce the Problem
Additional context
I first tried SteVe.3.4.0, but got above error. I then tried to go back to SteVe.3.3.2. Both compiled successfully with maven, but refused to start running. I would appreciate if I can get either version running. Please assist.