Solved ScreenConnect agent on Fedora fails rpm install
-
The normal process to install the
rpmon a Fedora desktop is
rpm -U ConnectWiseControl.ClientSetup.rpm
Unfortunately that is now failing to verify as you casn see int he screenshot.Adding
--nodigestgets around the problem.
-
I used the support form to send in a ticket. We'll see what happens.
-
Which Linux distro do they use for testing there rpm package with?
-
@black3dynamite said in ScreenConnect agent on Fedora fails rpm install:
Which Linux distro do they use for testing there rpm package with?
My guess is that they don't test it at all.
-
I don't remember what NTG is using... Ubuntu?
-
@gjacobse said in ScreenConnect agent on Fedora fails rpm install:
I don't remember what NTG is using... Ubuntu?
For the jump box? Yes, it is talked about in that other thread.
But SC works fine on Fedora + Cinnamon minus that lock screen issue. So for my access my desktop, that is not a problem. I always know what login is sitting there.
-
@gjacobse said in ScreenConnect agent on Fedora fails rpm install:
I don't remember what NTG is using... Ubuntu?
We use Fedora desktops.
-
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
The normal process to install the
rpmon a Fedora desktop is
rpm -U ConnectWiseControl.ClientSetup.rpm
Unfortunately that is now failing to verify as you casn see int he screenshot.Adding
--nodigestgets around the problem.I added
--nofilesas well. I can't remember if just --nodigest did the trick as well. I actually contacted ConnectWise support about it -- not helpful. -
This is still happening on the current version.
Client Version: 6.9.21415.6941 -
Installing an RPM directly is never a good idea. What happens when you run
yum localinstall package.rpm? -
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
Installing an RPM directly is never a good idea. What happens when you run
yum localinstall package.rpm?You have no idea what you are talking about.
But for the record,
$ sudo dnf localinstall ConnectWiseControl.ClientSetup.rpm [sudo] password for jbusch: Last metadata expiration check: 0:19:29 ago on Wed 23 Jan 2019 12:56:17 PM CST. Dependencies resolved. ==================================================================================================================================== Package Arch Version Repository Size ==================================================================================================================================== Upgrading: screenconnect-20d3659f902a4dc6 noarch 6.9.21415.6941- @commandline 670 k Transaction Summary ==================================================================================================================================== Upgrade 1 PackageTotal size: 670 k Is this ok [y/N]: y Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Error: Transaction check error: package screenconnect-20d3659f902a4dc6-6.9.21415.6941-.noarch does not verify: no digest Error Summary ------------- -
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
Installing an RPM directly is never a good idea.
Why not?
-
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
You have no idea what you are talking about.
I didn't say it would work. I only said standalone RPM installs can be problematic in a yum/dnf managed system. But cheers on being an @hole, well done
-
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
Why not?
Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.
yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.
-
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
Why not?
Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.
yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.
And this just reinforces that you have no idea what you are talking about.
If you had any clue, you would realize that this is a on the fly create RPM to install the client software specific to the installation it was created from.
There is no way possible for this to ever be involved in a repository in any fashion whatsoever.
-
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
And this just reinforces that you have no idea what you are talking about.
If you had any clue, you would realize that this is a on the fly create RPM to install the client software specific to the installation it was created from.
There is no way possible for this to ever be involved in a repository in any fashion whatsoever.
What I pointed at is the best practice for ANY RPM file. In this particular case you may be right, but if you deal with RPM based systems as much as I do, you'd do well to drop the attitude, you might actually learn something.
-
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
Why not?
Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.
yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.
I see your meaning now.
Installing an RPM directly is never a good idea.
I read this as never install RPMs directly, which wouldn't make sense, because for some things, such as ScreenConnect, create RPMs on demand; thus, they'd never be in a repo -- As Jared mention.
-
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
Why not?
Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.
yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.
I see your meaning now.
Installing an RPM directly is never a good idea.
I read this as never install RPMs directly, which wouldn't make sense, because for some things, such as ScreenConnect, create RPMs on demand; thus, they'd never be in a repo -- As Jared mention.
His point is that you can use yum or dnf instead of rpm directly.
All those tools should be pulling their information from the same database.
If an rpm requires dependencies that aren't currently installed but available in a repository on the system, it's much more convenient to install it using yum or dnf rather than rpm.
-
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
I read this as never install RPMs directly, which wouldn't make sense, because for some things, such as ScreenConnect, create RPMs on demand; thus, they'd never be in a repo -- As Jared mention.
You read it correctly. My point is, best practice is to always use yum, even for standalone RPMs, because $reasons (and if there are deps, yum will automatically resolve them). Even if the best practice is not applicable and you have a completely standalone package there, it's best to stick to best practices, just like you put on a seatbelt even when you drive 20 yards to your mailbox and back.
-
@dyasny yum/dnf does not magically resolve dependencies.
The RPM has to have them noted.
