Project

General

Profile

Bug #2458

Amahi 12 with fedora 34 and platform 11.9

Added by cpg 6 months ago. Updated 5 months ago.

Status:
Assigned
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
04/28/2021
Due date:
% Done:

0%


Description

These are the notes for Amahi 12 on Fedora 34.

The f34 public repo has been populated.

So far, after some amount of recompiling, it exhibits the following issues:

  • hda-install seems to work ok
  • upon rebooting, hda-ctl is not running
  • web interface is not working by IP address, despite httpd and puma services being running
  • the /etc/httpd/conf.d/01-platform.conf file has an unexploded line: ServerAlias hda.HDA_DOMAIN

Capture.PNG View (17.4 KB) bigfoot65, 05/17/2021 06:08 PM

History

#1 Updated by cpg 6 months ago

There is also a message that reads like this

Apr 28 19:26:28 fedora systemd-resolved[584]: Using degraded feature set TCP instead of UDP for DNS server 192.168.32.20.

while (seemingly) harmless, it is quite annoying, as it's spamming the logs every 6 seconds.

#2 Updated by cpg 6 months ago

It's clear in F34 we have to use the systemd-resolved service, since there are new layers in DNS resolution.

It appears that the best thing is to use something like a /etc/systemd/resolved.conf.d/hda.conf file, though the directory does not exist by default and it appears it's hard for the system to accept it.

There is also the issue that the dnsmasq files are not generated, so that has to be rooted out first.

#3 Updated by cpg 6 months ago

After some prep, I updated my HDA to F34 and it was surprisingly easy and quick. More than ever.

#4 Updated by bigfoot65 6 months ago

I upgraded my backup HDA to Fedora 34. Easy as you said and didn't take too long.

Issues so far is cannot access dashboard. I used IP Address and it says:

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

I will play with it more once I can get the dashboard working with IP address.

#5 Updated by cpg 6 months ago

Try this work-around to see if the platform works, as root:

cd /var/hda/platform/html/
mkdir -p tmp/pids/
chown apache:apache -R tmp
systemctl restart hda-platform

#6 Updated by cpg 6 months ago

Scratch that. This rpm was pushed to the f34 repo: hda-platform-11.9.1-1.x86_64.rpm and a simple upgrade should fix this issue without the need of a workaround. Please confirm.

#7 Updated by cpg 6 months ago

I cannot seem to build hda-ctl so that it does not crash upon launch on f34. I do not know yet why. The f33 version may work (but I am not sure if that is what is in the repo), i.e. what's in the repo may work or not.

#8 Updated by bigfoot65 6 months ago

I did the work around before I saw the guidance about the upgraded rpm. The dashboard is now working for me using IP address.

Apps appear to be working as well. I will test more and report back.

#9 Updated by cpg 5 months ago

OK, update on hda-ctl.

I found that hda-ctl apparently gets killed unceremoniously with a SIGTERM signal when trying to connect to the DB (even if the DB server is running) and the DB is there.

This is weird. It should instead .. get an error and we'd see quickly the DB is not set up, and the code could try again after some time (which is what the code does), until the install is ready. Killing it is just crazy.

This abrupt TERMination took a while to dig into, and I am not sure why this happens yet.

#10 Updated by cpg 5 months ago

Holy sh*t. It was that now the DBI connect in perl is not "DBI:mysql:database=.." but "DBI:MariaDB:database=.." (with that precise capitalization too). OMG!

Also, we did some improvements to hda-ctl to be more nd compliant, so now it has accurate status, standard PID management through systemd proper detection and quick shutdown of the daemon, etc.

All that means that there is no longer a .pid file in the filesystem, which may impact our use of monit, so that may be broken.

Should we ditch monit? it was nice while it lasted, but it has this tendency to get into loops, logging tons of data, etc.

hda-ctl-11.9.2 is in the f34 repo and it ought to be a smoother ride (modulo monit).

#11 Updated by cpg 5 months ago

Oh, and the platform will need to be adjusted to detect hda-ctl as well. Soon.

#12 Updated by bigfoot65 5 months ago

Wow, I bet that wasn't easy to find.

As for Monit, I think it's time to remove it. SystemD can do just as good of a job for most services.

systemctl --is-active service

Works just as well, although it does not autostart unless programmed into the service file.

You can also use:

systemctl enable --now service
systemctl disable --now service

To enable/start and disable/stop the service as well. I've used in with the apps I built for Greyhole and Admin Console.

Seems the less we add the better by using the system that's already in place.

Using these commands should allow some reuse of the Server's Tab. I presume you would need to update that a bit and the Testmaster as well.

#13 Updated by bigfoot65 5 months ago

Appears the dashboard does not work with IP Address :(

We're sorry, but something went wrong.

If you are the application owner check the logs for more information.

#14 Updated by cpg 5 months ago

the following have been pushed to the repos and should be compatible to work with each other

hda-ctl-11.9.8-1
hda-platform-11.9.2-1

further reports on issues will be appreciated.

#15 Updated by bigfoot65 5 months ago

I cannot uninstall apps. I presume it's because the app was installed in Fedora 33 and the app store is Fedora 34.

Is there a manual way to uninstall apps?

#16 Updated by cpg 5 months ago

hda-platform-11.9.3-1 has been released to the repos with a fix for reliability issues in the dashboard that may have prevented app installation, uninstallation, propagation of settings and more.

app uninstall appears to work reliably now.

#17 Updated by bigfoot65 5 months ago

Still having issues with installing Amahi. Once installed and server is rebooted, I cannot get past the dashboard initialization portion.

Using IP address and hda.amahi.net, I get an error:

We're sorry, but something went wrong.

If you are the application owner check the logs for more information.

Also the background and Amahi log are not present, just a white screen with the initialization dialog box.

When verifying service status oh hda-platform, I see the following message:

Authlogic has no plans yet to deprecate this >
we recommend transitioning to a more secure, >
like scrypt. Adaptive algorithms are designed>
attacks, and over time the iteration count ca>
slower, so it remains resistant to brute-forc>
the face of increasing computation power.
Use the transition_from_crypto_providers opti>
painless for your users.
* Listening on http://127.0.0.1:9292

#18 Updated by cpg 5 months ago

Hmm. The error will be at the bottom of /var/hda/platform/html/log/production.log. Can you locate it?

#19 Updated by bigfoot65 5 months ago

I see this:

I, [2021-05-15T11:39:03.514591 #1661]  INFO -- : [c063d289-d7da-49b5-9e90-311b1ed32add] Started POST "/user_sessions/initialize_system" for 192.168.1.97 at 2021-05-15 11:39:03 -0500
I, [2021-05-15T11:39:03.515583 #1661]  INFO -- : [c063d289-d7da-49b5-9e90-311b1ed32add] Processing by UserSessionsController#initialize_system as HTML
I, [2021-05-15T11:39:03.515679 #1661]  INFO -- : [c063d289-d7da-49b5-9e90-311b1ed32add]   Parameters: {"authenticity_token"=>"[FILTERED]", "username"=>"amahi", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]", "commit"=>"Create"}
I, [2021-05-15T11:39:03.745259 #1661]  INFO -- : [c063d289-d7da-49b5-9e90-311b1ed32add] Completed 500 Internal Server Error in 229ms (ActiveRecord: 182.8ms | Allocations: 16760)
F, [2021-05-15T11:39:03.746971 #1661] FATAL -- : [c063d289-d7da-49b5-9e90-311b1ed32add]
[c063d289-d7da-49b5-9e90-311b1ed32add] Errno::ENOTCONN (Transport endpoint is not connected - send(2)):
[c063d289-d7da-49b5-9e90-311b1ed32add]
[c063d289-d7da-49b5-9e90-311b1ed32add] lib/command.rb:37:in `send'
[c063d289-d7da-49b5-9e90-311b1ed32add] lib/command.rb:37:in `execute'
[c063d289-d7da-49b5-9e90-311b1ed32add] app/models/user.rb:179:in `before_save_hook'
[c063d289-d7da-49b5-9e90-311b1ed32add] app/controllers/user_sessions_controller.rb:95:in `initialize_system'

#20 Updated by cpg 5 months ago

What version of hda-ctl is in the machine?

Should be hda-ctl-11.9.8-1. Can you try and restart it with:

systemctl restart hda-ctl

#21 Updated by bigfoot65 5 months ago

Installed Packages
hda-ctl.x86_64 11.9.8-1 @amahi

Still no luck. This is a new Amahi install for my test machine.

#22 Updated by cpg 5 months ago

Gets stuck during initialization time. But the initialization appears to work.

It may be related to some sleep statements. So far no luck.

#23 Updated by cpg 5 months ago

I tried to add a deepeer listen queue, but it still appears to get stuck.

The new library for sockets we're using has a different semantics than before. Grr.

#24 Updated by cpg 5 months ago

thanks for the testing. it helps to test things out well outside of development mode.

now, because this appears to be a race condition, i increased the "listen" lines, which may or may not work in the long run and made the system initialize.

you can

1) proceed testing, or, if you prefer (e.g. if you have a snapshot that makes it easier),

2) test initialization again.

I am interested in 2, ov course, since this may work or not. sadly, i do not currently know if the current "solution" will work reliably.

this race condition appears to be in initialization only, so far, since it's a relatively "heavy" operation in the system. it does not appear to happen in normal operation, but it could well hamper app installs/uninstalls, as these are heavy ops. i have tried installing and uninstalling a couple of apps and things appear to work well with no signs of the race condition.

i know it sucks having this potential race condition dangling over our heads. i do know.

FYI the signature of this race condition is the "Errno::ENOTCONN (Transport endpoint is not connected - send(2)" in the production.log file.

in addition, two new RPMs have been released to the f34 with fixes to make things more reliably and also, to fix a couple of ruby-3.0 upgrade bugs that i noticed in the platform while debugging this.

hda-ctl-11.9.9-1.x86_64.rpm
hda-platform-11.9.4-1.x86_64.rpm

#25 Updated by bigfoot65 5 months ago

Just tested a new install and the initialization worked perfectly using the IP Address.

Will kick the tires a bit and let you know how it goes.

#26 Updated by bigfoot65 5 months ago

One issue that I notice immediately is the user login is a white screen with the Login Box. Not sure what happened to the background.

I've attached an image.

#27 Updated by bigfoot65 5 months ago

Still checking things out. I think we should remove the amahi-anywhere from the install. Let users choose if they want to install it or not.

Also, does not appear that all shares are being created when accessing the Shares tab. Docs, TV, and Public directories are not present. Public is also still created with the wrong name. Should be Public vs public on the drive for Amahi Sync or the app should be updated to use public.

DHCP server appears to remain active when unchecked. I see devices on my network that are reflecting DHCP from the test HDA.

The log message below is still present:

You have selected Sha512 as your authlogic crypto provider. This algorithm
does not have any practical known attacks against it. However, there are
better choices.

Authlogic has no plans yet to deprecate this crypto provider. However,
we recommend transitioning to a more secure, adaptive hashing algorithm,
like scrypt. Adaptive algorithms are designed to slow down brute force
attacks, and over time the iteration count can be increased to make it
slower, so it remains resistant to brute-force search attacks even in
the face of increasing computation power.

Use the transition_from_crypto_providers option to make the transition
painless for your users.

#28 Updated by cpg 5 months ago

You have selected Sha512 as your authlogic crypto provider.

This one we have to ignore.

#29 Updated by bigfoot65 5 months ago

Any way to block the output in the log of this warning?

Also available in: Atom