Failed to connect to remote server
Closed this issue · 27 comments
Hi,
I am testing minarca backup software. I installed the server and client software on the host. I was able to connect without any problems for a few days and then I can't connect to the server. The ssh service works normally, I don't have a firewall. I connect to 127.0.0.1:8080. I deleted the repo, the user, created a new one and still nothing. I deleted all the keys in the admin profile. I have no idea how to solve the problem
Hello @satkas
Thank you for reaching out regarding the connection issue you are experiencing. To assist you further, I would need some additional information about your setup. In order to diagnose the problem effectively, I suggest taking a look at the minarca log file, which contains valuable information related to this type of issue.
The log file contains detailed information that can help us identify the root cause of the problem. If you are unsure about how to interpret the log file or find it inconvenient, you can share the log file with us. However, please keep in mind that the log file may contain personal information such as file names.
To ensure the privacy of your information, I recommend sharing the log file privately by sending it to support@ikus-soft.com. This way, we can carefully analyze the log file and provide you with a more accurate solution to your connection issue.
Thank you for your cooperation, and we look forward to assisting you further.
Thank You
I sent an e-mail
@satkas
The magic line is this one:
remote: [minarca@127.0.0.1](mailto:minarca@127.0.0.1): Permission denied (publickey,password).
Your SSH public key get refused by the remote server. Hopefully, the next release got a major improvement regarding the error messages displayed to the user.
That could be cause by a number of reasons.
Take a look at your SSH authentication log. On Debian server the logs are located in : /var/log/auth.log
I don't have a /var/log/auth.log file (debian 12)
I've attached a dump of the journactl
cze 20 19:20:04 dell sshd[6966]: Connection closed by authenticating user minarca 127.0.0.1 port 50396 [preauth]
cze 20 19:20:04 dell minarca-client.desktop[6704]: rdiff-backup exit with non-zero code
cze 20 19:20:04 dell minarca-client.desktop[6704]: ssh connection error
cze 20 19:20:04 dell minarca-client.desktop[6704]: Traceback (most recent call last):
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/SetConnections.py", line 193, in check_connection_version
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/connection.py", line 526, in call
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/connection.py", line 436, in reval
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/connection.py", line 379, in get_response
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/connection.py", line 284, in _get
cze 20 19:20:04 dell minarca-client.desktop[6704]: rdiff_backup.connection.ConnectionReadError: Truncated header string (problem probably originated remotely)
cze 20 19:20:04 dell minarca-client.desktop[6704]: During handling of the above exception, another exception occurred:
cze 20 19:20:04 dell minarca-client.desktop[6704]: Traceback (most recent call last):
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "minarca_client/core/init.py", line 482, in _rdiff_backup
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/Main.py", line 414, in Main
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/SetConnections.py", line 86, in cmdpair2rp
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/SetConnections.py", line 183, in init_connection
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/SetConnections.py", line 205, in check_connection_version
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "rdiff_backup/log.py", line 206, in FatalError
cze 20 19:20:04 dell minarca-client.desktop[6704]: SystemExit: 1
cze 20 19:20:04 dell minarca-client.desktop[6704]: The above exception was the direct cause of the following exception:
cze 20 19:20:04 dell minarca-client.desktop[6704]: Traceback (most recent call last):
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "minarca_client/ui/setup.py", line 84, in _link_task
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "concurrent/futures/thread.py", line 57, in run
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "minarca_client/core/init.py", line 379, in link
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "minarca_client/core/init.py", line 552, in test_server
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "minarca_client/core/init.py", line 485, in _rdiff_backup
cze 20 19:20:04 dell minarca-client.desktop[6704]: File "minarca_client/core/exceptions.py", line 20, in raise_exception
cze 20 19:20:04 dell minarca-client.desktop[6704]: minarca_client.core.exceptions.SshConnectionError: Unable to connect to the remote server using SSH without password. The problem may be with the remote server. If the problem persists, contact your system administrator to check the SSH server configuration and a possible firewall blocking the connection
How does the client connect to the server? By the key or by the password that I create on the server (creating the user)? Why do I see in the logs that minarca connects via ssh? I guess it should be the user I assume on the server, I couldn't find an answer in the documentation.
@satkas
Minarca client will use HTTPS and SSH to communicate with the server.
During the initial configuration, the Minarca client will generate a private and public key to be used for SSH communication. This identity is kept in ~/.config/minarca on Linux. To complete the configuration, Minarca will try to push the identity using HTTP(s) communication to the web server. By doing so, the server will keep the SSH identity in database and also update the /backups/.ssh/authorized_keys that should be use by your SSHD server for password less authenticate for minarca posix user. On the server side, /backups/ is expected to be the home of minarca posix user.
Once the initial configuration is complete, the username and password is forgot and only the SSH identity is used to complete the backup.
I hope that help you.
Thank You
I deleted the ~/.config/minarca and ~/.local/share/minarca folders
I changed to the default repository folder and it works.
While using minarca backup, I changed the default location of the repository in the configuration file, maybe that was the reason?
I forgot to write that I like the application very much. I used to use backuppc but I might switch to minarca
While using minarca backup, I changed the default location of the repository in the configuration file, maybe that was the reason?
That might be it. Could you document which configuration option you changed ?
Could you also share the permissions on that folder ? If minarca user doesn't have permissions to that folder that might cause problem...
I will try to reproduce the problem later this week.
I forgot to write that I like the application very much.
Thanks ! I've put a lot of effort in this project.
I used to use backuppc but I might switch to minarca
What make you switch from backuppc to Minarca ?
In the configuration file /etc/minarca/minarca-server.conf I added the option MinarcaUserBaseDir=/media/tk/bck/minarca/
The permissions are good (as a minarca user, I was writing to the directory).
I read about minarca here https://www.linuxjournal.com/content/minarca-backup-solution-youll-love.
BackupPC is ok, but complicated in my opinion (a lot of options). I want to make a simple backup. Minarca seems perfect. Too bad there's no deduplication. This can be solved by creating a repository on ZFS or BTRFS
In the configuration file /etc/minarca/minarca-server.conf I added the option MinarcaUserBaseDir=/media/tk/bck/minarca/
The permissions are good (as a minarca user, I was writing to the directory).
I will investigate what wrong with it later this week.
I read about minarca here https://www.linuxjournal.com/content/minarca-backup-solution-youll-love.
BackupPC is ok, but complicated in my opinion (a lot of options). I want to make a simple backup. Minarca seems perfect.
Too bad there's no deduplication. This can be solved by creating a repository on ZFS or BTRFS
Minarca strives to prioritize simplicity, aiming to simplify complex tasks whenever possible. However, there may be occasional instances of failure, as you have experienced.
It is not feasible to achieve deduplication with rdiff-backup.
The objective of rdiff-backup is to create a replica of the files and folders similar to the original source. In the event of a catastrophic loss, you can confidently recover your data by simply copying and pasting, even if your repository is severely damaged. This means that you could recover your data even without relying on Minarca or rdiff-backup. Personally, this feature enhances my trust in the backup process.
Why are rdiff-backup packages downloaded from your repository when rdiff-backup in debian 12 is newer?
@satkas
The reason why the rdiff-backup packages are downloaded from our repository instead of using the ones provided by Debian 12 is due to several factors. Firstly, Minarca server is designed to support multiple versions of rdiff-backup for backward compatibility. These versions include 1.2.8, 2.0.x, and soon 2.2.x. However, the packages distributed by Debian cannot be installed side-by-side, which is a requirement for Minarca's functionality.
Moreover, the packages distributed within Minarca are pre-compiled with a specific version of Python that is guaranteed to work in any Debian or Ubuntu distribution, regardless of the Python version provided by the operating system. This ensures compatibility across different environments.
Additionally, there are occasions when we need to apply additional patches to the original source code for compatibility reasons. While most of these patches are eventually merged upstream within a few months, we apply them directly to the packages distributed by Minarca to avoid any disruption for our end-users.
In summary, the rdiff-backup packages distributed by Minarca are specifically tailored and known to work seamlessly with Minarca, whereas the packages provided by Debian may not fulfill these requirements.
I noticed that if I move the default repository to another place with sudo usermod -d /home/minarca -m minarca and not change only in the dashboard (when creating a user), it works fine. Of course, I add the variable (MinarcaUserBaseDir) in both cases to the server configuration. Maybe it's worth considering creating a repository after first entering the dashboard?
I'm not sure to understand you last comment. Is it a way to move the default backup location ? And it's working for you ?
Once I install the server app and stop the service then I move the default repository to another location.
I replace the option in the configuration file with the correct repository. I go to the dashboard and replace the path with the admin user. then it just adds new customers. it works
@satkas I'm glad you found a way to move your default repository location to the path you wanted. I took note to simplify that process in a future version to make sure it's robust.
Thanks a lot for your feedback !
I'm closing this issue. Don't hesitate to re-open this issue or create a new one if you have question.
@satkas I'm working on reproducing the problem you had. I will need to understand why did you ran sudo usermod -d /home/minarca -m minarca in the first place ? It's not part of the documentation and I can't understand why you decided to manually change the home directory of minarca user. Like, why would I change the home directory of apache server to something else then /var/www. I feel it's unusual to change the home directory of system account.
Could you explain more your reasoning ?
We are talking about the server (minarca). Probably 90% of people will adapt to the documentation. But there is a percentage of people who, for example, have little space on the / partition and would like to be able to change the default path (/backups). So I decided to move the default path to another partition (/home/minarca)
Thanks for your feedback.
Could you take the time to review the updated documentation and give me your feedback:
Of course,
Thanks for your feedback.
Could you take the time to review the updated documentation and give me your feedback:
It's good. Now you can understand the idea of changing the default repository.
Hi,
Generally, if I have the ipiphany browser set as the default browser (default in gnome), I have the following syslog logs when I click
lis 28 09:29:01 dell systemd[2834]: Started app-gnome-minarca\x2dclient-6096.scope - Application launched by gnome-shell.
lis 28 09:29:01 dell crontab[6101]: (tk) LIST (tk)
lis 28 09:29:01 dell crontab[6102]: (tk) LIST (tk)
lis 28 09:29:02 dell minarca-client.desktop[6096]: Fontconfig warning: "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 6: unknown element "reset-dirs"
lis 28 09:29:02 dell crontab[6107]: (tk) LIST (tk)
lis 28 09:29:02 dell crontab[6108]: (tk) LIST (tk)
lis 28 09:29:02 dell crontab[6109]: (tk) LIST (tk)
lis 28 09:29:02 dell crontab[6110]: (tk) LIST (tk)
lis 28 09:29:02 dell crontab[6111]: (tk) LIST (tk)
lis 28 09:29:07 dell opensnitch_ui.desktop[3565]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
lis 28 09:29:12 dell org.gnome.Epiphany.desktop[6153]: epiphany: symbol lookup error: /lib/x86_64-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Get_Transform
lis 28 09:29:27 dell org.gnome.Epiphany.desktop[6164]: epiphany: symbol lookup error: /lib/x86_64-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Get_Transform
lis 28 09:29:32 dell org.gnome.Epiphany.desktop[6181]: epiphany: symbol lookup error: /lib/x86_64-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Get_Transform
lis 28 09:29:35 dell systemd[2834]: app-gnome-minarca\x2dclient-6096.scope: Consumed 2.651s CPU time
If I set firefox to esr 115, I have the following logs in syslog (I inform you that I only click on the items in the menu that are faulty. Of course, when I click on the correct item, e.g. full restore, I have many more logs)
lis 28 09:34:42 dell systemd[2834]: Started app-gnome-minarca\x2dclient-6954.scope - Application launched by gnome-shell.
lis 28 09:34:42 dell crontab[6959]: (tk) LIST (tk)
lis 28 09:34:42 dell crontab[6960]: (tk) LIST (tk)
lis 28 09:34:43 dell minarca-client.desktop[6954]: Fontconfig warning: "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 6: unknown element "reset-dirs"
in the file minarca.log there is only (.local/share/minarca/minarca.log)
2023-11-28 09:42:26,401 [7522][DEBUG][ThreadPoolEx] Starting new HTTPS connection (1): latest.ikus-soft.com:443
2023-11-28 09:42:27,471 [7522][DEBUG][ThreadPoolEx] https://latest.ikus-soft.com:443 "GET /minarca/latest_version HTTP/1.1" 200 5
@satkas I don't see anything relevant in the log. Are you seeing something in the log when you click on the "view my account online" ?
If you are willing, you may also execute the following code.
python3
import webbrowser
webbrowser.open('http://google.com')
That would open the webbrowser to the given URL. If not, it's an issue with the webbrowser library.
I have a client window and terminal set up. When I click on the my account link, nothing logs in.
After executing the code below, a tab opens in my browser.
$ python3
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> webbrowser.open('http://google.com')
True
>>>
@satkas I just notice we are exchanging in the wrong ticket :/
When you click on the "view my account online" or "help" the button, that trigger a call to webbrowser.open('http://google.com') if manually executing the code is working, I'm not sure what wrong with Minarca. Which version of Minarca are you running ?
I see you are running wayland, I will check if it's a wayland thing.
My version is 5.0.1
I'm attaching a video
wideo.webm