I was able to do steps 1 & 3, but when I tried finding /etc/pam.d/common-auth there was no /etc/pam anything. Being unfamiliar with this particular os, can you off some supporting guidance please?You can gain root access to solar-assistant, it's an easy way to go.
get your sdcard into an other raspi or linux machine
Next modify:
Like GregTR here said: do delete the line
BUT they also mucked with the /etc/pam.d/common-auth file and added a one liner.
Code:
auth [success=die default=ignore] pam_localuser.so
That's a bit over the top I think.It's a shame the guys at solar assistant promised "configurable alerts/email notifications" since late last year and up till now there are still shifting the expected date. Deceiving people into purchasing their product.
I don't think so. It's one of the feature that made me go for it. What they essentially do with new updates is adding support for more inverters. I want to get notified when my battery is going down or when there's a warning or alarm. No one wants to watch the log all the time.That's a bit over the top I think.
So you bought it only for a feature that was not yet implemented and which indicated an estimated date it would be and consider that deceptive.It's one of the feature that made me go for it.
Or you can just add Home Assistant on a separate server like everyone else does. I would not want SA and HA on the same RPi, that would have potential performance issues.Or if they don't want to implement it, they should not lock ones device so one can use one device for both this and home assistant. Or they should give users the option of bundling home assistant into it.
BTW what would happen if I hooked my single EG4LL into the Pi while I am still getting my closed loop battery info for my other four eFlex packs from the Inverter. I suspect that SA would show me only the SOC of the EG4? That is why I have not bothered trying but now I am curious to know if I would see them as separate numbers.
Anybody else been running it for over a year?
I have noticed the update time has really slowed down as the database grows. It will sometimes react to a load change in 2-3 seconds and at other times it will take 10-15 seconds to react.
As soon as I know Sol-Ark has migrated my data safely to their new server I am putting in a new SD card with a fresh install and see if a clean Db fixes the issue.
having the same issue since tonight..Hello, I've been using SA since the middle of last year. This evening it stopped giving me access to the https://r*****d.eu.solar-assistant.io/ site or the android app but I can still access it on my local network, 192.168.1.***. I updated SA to the latest 2023-02-28 software but this didn't solve the problem. What is the next step to solve this issue?
Thanks in advance, Greg
Scotland, seems to be working again this morning.having the same issue since tonight..
are you in the eu ?
A little confused.You can gain root access to solar-assistant, it's an easy way to go.
get your sdcard into an other raspi or linux machine
modify sshd_config like this one:
Bash:# This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. Include /etc/ssh/sshd_config.d/*.conf Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes # Expect .ssh/authorized_keys2 to be disregarded by default in future. #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no
Next modify:
Like GregTR here said: do delete the line
BUT they also mucked with the /etc/pam.d/common-auth file and added a one liner.
Code:
auth [success=die default=ignore] pam_localuser.so
modify shadow
1.line:
/etc/shadow
root:$y$j9T$ENxjb9crH9Rf43ZvEU5K//$gUc0L1WSGNRiLA5a1w5vxKONSaa2LrxThvcoyShmVh8:1
so root password will be: 1234
reboot and ssh into your solar-assistant ip as root and password: 1234
easy
This is what mine looks like now :A little confused.
i can't find that line in /etc/pam.d/common-auth
am i supposed to add it?
Yep that will work for getting at the files. But if the main os is on the sd card its going to fail from rewrites.How about adding a SSD and boot from that..
Sometime KISS is the best answer