Custom hostname issue + a few other issues


#1

Using Ubuntu 16.04 on OVH.

When using a custom hostname, attemping to go to server.example.com will go to http://server.example.com/ (not https) and ask for a username and password.

Once entered, you’ll get the typical invalid SSL page, when proceeding from this point it’ll now go to https://server.example.com/ and it’ll ask for a username and password again which will take you to QuickBox.

I’m guessing this could be fixed by redirecting http to https in .htaccess but it’d be good to see a fix for this in an official release.

Another issue is that in the Service Status all of the services show as Disabled, I’m not sure if that’s caused by the /home issue as I haven’t fixed that yet.

P.S. When will the /home fix be in the install process?


#2

Thanks for the report @Vustom.

We are currently sorting out the multiple auth issues with https://. This isn’t necessarily a bug as much as it is apache’s basic behavior.

This happens even if you navigate to https:// on the first initial pass as well. The reason for this is due to requesting auth to be processed for both ruTorrent as well as the QuickBox dashboard, as /rutorrent is an alias in the apache vhost config. Since the Dashboard is the entry point beyond and within rutorrent, ie; /srv/rutorrent/home it is requesting auth twice. This is also why once you are logged in to the dashboard, you shouldn’t have to enter credentials again to enter ruTorrent.

As a test: Try just going to https://your_domain.com(or ip)/rutorrent - you’ll notice there is only one request for auth.

Yes, this is related to the /home primary partition. On the tests we’ve run, this has popped up and is usually resolved by adjusting the mount points.

As per the /home fix, this will be completed today and once the beta squad has given it a run and we see it fit for release, it will be available. I see this happening by later today… as it should had been released yesterday… but due to a heavy workload it got delayed.


#3

@JMSolo when do you think the auth issues will be resolved, and will there be an upgradeQuickBox (similar to upgradeBTSync) command at some point?


#4

Again, the auth issues are basic apache design due to the nature of how we have the QuickBox dashboard setup. The dashboard itself relies on hooks from ruTorrent to gather some of it’s more basic functions, thus, having it set within ruTorrent is the best aproach to this… a side-effect is the double requests for auth (only on the dashboard)

There is currently no present timeline on fixing the auth issues as there are a couple of other priorities taking place at the moment… and you pretty much nailed them both.

  1. Fix /home primary installs - option etc.
  2. API for easy upgrades.

In regards to upgrading. This is going to be using an API per latest/release within the GitHub repo. The API call is already built into the dashboard, it just is not enabled yet… not until I am certain it passes without borking installations.

Here’s the tidbit for review:
++ This is located within the /srv/rutorrent/home/inc/panel.header.php file

  <script>
  var gitHubPath = 'Swizards/QuickBox';  // quickbox repo
  var url = 'https://api.github.com/repos/' + gitHubPath + '/tags';

  $.get(url).done(function (data) {
    var versions = data.sort(function (v1, v2) {
      return semver.compare(v2.name, v1.name)
    });
    $('#version-result').html(versions[0].name);
  });
  </script>

The goal is to make it as simple as a notice appearing on the dashboard (only seen by the master account) informing the user there is an update available. You then simply click a button to run the update. It will be similar to the notice that pops up on the https://quickbox.io entry page towards the bottom.


#5

@JMSolo once the API for upgrades is released, will there be a wiki post on how to go about updating our existing installations of QuickBox to get the automatic upgrades?


API updates and upgrading
#6

i would imagine that once it’s done all the wiki will be filled out for the stuff needed to use the scripts provided.


#7

hey how hard would it be to do a auto update every week? so that it’s always up-to-date without human interaction.

rather than button. i know button is simple but why need it if its auto.
windows 10 does it why not a seedbox lol


#8

@dtech and @Vustom, a conversation about API would merit a new thread. Just in case anyone else wants to read about how the API would work and follow explanations / help develop… they wouldn’t be looking for such a topic in this thread.

Topic on API can be continued here:


#9

Has the bugfix been released yet? Have been holding off on an install for another server but may just go ahead anyways if it’s not out yet.

edit: nvm, checked the github readme and not the one here


#10

/home primary mount server setups are now supported via version 2.2.0.

The Changelog can be found here:


#11