Yes, as I now understand, that is a default VirtualBox file that you get when you download VirtualBox. That is vboxweb-service located by default on linux at /lib/systemd/system/vboxweb-service.service
It has been changing to its default parameters when I have updated Virtualbox in the past, aka my edit is removed.
Oracle Extension Pack vboxweb-service on Fedora 5.3.6-200.fc30.x86_64 blocked by firewall
-
EternalNoob
- Posts: 8
- Joined: 22. Oct 2019, 21:34
Re: Oracle Extension Pack vboxweb-service on Fedora 5.3.6-200.fc30.x86_64 blocked by firewall
... the only problem is that this file is actually generated by the installer, so it's not so easy to change.
Long story short, any 6.0.15 test build starting with r135092 should have this fixed. Yes, I know, the current ones are older. Should change in the not too distant future. Worst case Monday.
Long story short, any 6.0.15 test build starting with r135092 should have this fixed. Yes, I know, the current ones are older. Should change in the not too distant future. Worst case Monday.
-
socratis
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Oracle Extension Pack vboxweb-service on Fedora 5.3.6-200.fc30.x86_64 blocked by firewall
Found the file, thanks for that!
If that's the case, then I'm going to make a 180º and call this a VirtualBox issue then. So much so, that I'll ask you if you could actually create a new ticket in the Bugtracker.
After a 5' short talk over IRC with the developers, the fix will show up in the next 5.2.x and 6.0.x maintenance releases, and will be included in 6.1.0 final (hopefully). I'll update the thread with the source code patch when that comes in.
But 'klaus' already posted, while I was holding on with a "Draft post" for confirmation that the patch was in...
If that's the case, then I'm going to make a 180º and call this a VirtualBox issue then. So much so, that I'll ask you if you could actually create a new ticket in the Bugtracker.
| Edit: |
But 'klaus' already posted, while I was holding on with a "Draft post" for confirmation that the patch was in...
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Re: Oracle Extension Pack vboxweb-service on Fedora 5.3.6-200.fc30.x86_64 blocked by firewall
Note that the hideously complicated (and not terribly well documented, which is ultimately the much bigger problem) systemd dependency handling is ultimately to blame. No one seems to get it "right" even after years.
No wonder, just at the beginning of the week I ran into trouble with sshd.service myself (on RHEL/CentOS/OL 8, so nothing outdated) specifying that it can be run after "network.target". Which means that in typical network setups using DHCP one can't restrict sshd to listen on specific interfaces through the "ListenAddress" config options, because the service is started when the interface has been found, not when it is actually usable (having figured out the IP address). Really a non-improvement over the SysV init stuff (where this worked out of the box) to have to manually hack services files to get the service to work as it should.
The 6.0 test builds with the fix are available in the usual location.
No wonder, just at the beginning of the week I ran into trouble with sshd.service myself (on RHEL/CentOS/OL 8, so nothing outdated) specifying that it can be run after "network.target". Which means that in typical network setups using DHCP one can't restrict sshd to listen on specific interfaces through the "ListenAddress" config options, because the service is started when the interface has been found, not when it is actually usable (having figured out the IP address). Really a non-improvement over the SysV init stuff (where this worked out of the box) to have to manually hack services files to get the service to work as it should.
The 6.0 test builds with the fix are available in the usual location.