Can't enforce Hostname

Support License
#1

Hey there!

I have an issue in regards to the hostname of the machine. Due to deploying Duplicacy with a Kubernetes Cluster I am unable to enforce a specific hostname for the running pod, therefore the pod gets a different hostname everytime the machine reboots.
I also can’t deploy the pod as a statefulSet due to limitations in the current TrueNas Scale build.
Is there any way I can circumvent this hostname issue?

Due to this problem my licences.json looks something like this:

    "duplicacy-ix-chart-559ffc6fcf-tfc49": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-57965d78ff-5755m": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-5f8cc596f5-srkzd": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-6d454cbd94-mrcxk": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-6d454cbd94-pk58k": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-6d454cbd94-sx4gd": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-75968b9bb8-p6c9d": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-789489d9fd-mtcqk": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-789489d9fd-rdmts": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-7cfb7cbd7f-5vq9t": {
        "license": "xx",
        "signature": "xx"
    },
    "duplicacy-ix-chart-858bdb96c8-w6lzs": {
        "license": "xx",
        "signature": "xx"

Sincerely,
Philipp

#2

Is there a way to assign a fixed hostname to each pod?

#3

Sadly, there is not.

#4

So I guess this issue is not getting resolved then?

#5

The actual issue here is relying on hostname for licensing. Prior discussion: Invalid or expired Web-UI license after reboot (Backups were working fine earlier today, and my license is valid well into 2022) - #8 by gchen.

1 Like
#6

If you can’t keep the same hostname, then you won’t be able to use the web GUI. I do not want to remove the hostname check.

#7

Warning: Rant alert incoming!!!

@gchen,

About a year ago you mentioned in an admirably open manner that Duplicacy-Web was not the commercial success you hoped it to be. In my opinion the statement above perfectly embodies why it never had a chance to be one and why it doesn’t deserve to be one. I understand that this is some harsh criticism, but I believe it is justified. Please allow me to explain, based on my experience.

I have three Duplicacy-Web lifetime licenses and one of them powers the MacBook Air of a family member living 9 times zones away. Her backups are stored on a NAS in my own home network. She is not computer-savvy and not particularly interested in it. In other words she’s the perfect “normal” user, who just wants things to work reliably and not have to tinker with something that in most cases she can’t fix anyway. It is also nearly impossible to get remote access to her computer, just because she’s always on the go and a difference of 9 time zones makes it even more difficult.

In July or August of 2021 I visited her and updated her MacBook to the then-latest version of Duplicacy-Web. I did a test run of the backup after rebooting her machine and things looked fine. Around September or Oktober I checked into her backup data from my local installation of Duplicacy-Web and noticed that I wasn’t getting any more backup versions from her Mac. I tried to schedule a session with her to take a look at things, but - as usual - she was just too busy. In April of 2022 I visited her again and noticed that the backup failed due to a license issue, even though at first glance the hostname matched. After some tinkering (changing the hostname in the Duplicacy web portal and then later changing it back) I finally got the license check to pass and directly launching a backup seemed to work again. Except when I rebooted her machine and let the scheduled backup kick in, it failed again with a license check failure.

At this point I simply gave up, because I didn’t have the time or the inclination to issue a support request for a machine that I have no reliable access to. Strangely enough a few weeks later her backups started coming in again. Though - as I just now noticed - her last backup was from two weeks ago, not sure why they stopped again.

Of course during all this I was never aware in a timely manner when a problem occurred, because the Web-app doesn’t provide the option to just email you, when they are problems, you either get emails or you don’t. And I always opt for don’t. That’s why I also missed that my own local backups stopped working at some point last year and only noticed it three weeks later. The problem was easily fixed (by deleting and recreating the docker container for Duplicacy-Web on my NAS), but one needs to know that a problem exists without being constantly bombarded with the “news” that everything is working fine.

Why am I telling you this? Because it demonstrates a few of the ways in which Duplicacy-Web as a product keeps failing me. The engine seems to work fine, but the user interaction with the product is a nuisance and the overall solution is just not reliable. It’s like a high-maintenance romantic partner that constantly needs an inordinate amount of attention for the relationship to not fall apart. And I don’t want a romantic relationship with my backup software, I want a professional relationship, where the professional/software does the job in a reliable manner, reaching out to me only when there’s a problem with doing the job, but otherwise leaves me alone.

As @saspus pointed out, you’ve been previously alerted to the problem with the current license verification logic and alternatives were suggested, yet apparently the feature is as unreliable as ever (even though (fixing it might have become a little easier). But that’s only touching up the symptoms and that only matters, if you a) notice the problem in a timely manner and b) have (local or remote) access to the machine. Those of us who (remotely) provide tech support to family members won’t have a) and frequently don’t have b) either. Thus we need the solution to not fail in the first place, if it can be avoided. And in the case of the licensing logic many fails can definitely be avoided, as more robust alternatives have been pointed out to you.

But just as you didn’t heed suggestions made years ago, that you provide an option to have Duplicacy-Web sent out emails only in case an error occurred, you didn’t heed the suggestion re. reliability improvements for the license verification. And all you have to say now is that you don’t want to change it. (The implication being “the customer be dammed” or “let them eat cake”.)

While it’s understandable that you can’t implement every suggestion, at this point in time Duplicacy-Web is still the same clunky mess that it was years ago, except years ago I still had hopes that it would improve over time. Well it did not.

And at this point I have given up any and all hope that Duplicacy-Web can ever be a low-maintenance solution and I expect it to always be a high-maintenance proof of concept, masquerading as a product. Thus I have stopped recommending it to friends and family and in December of last year. I bought a set of licenses from another backup software. I can’t say that it’s a competing product, because as I said, I don’t consider Duplicacy-Web to be a “product” anymore. For as long as it runs on my machine, I’ll still use it for backups, but at this point I consider it my tertiary backup “solution”, the other two are the relevant ones for me. I’m also going to migrate said family member’s MacBook Air to the recently bought backup software, so I won’t have any more hassles with that.

To the OP of this thread and anybody else reading this, I strongly suggest that you abandon the Web version of Duplicacy, if you want a reliable solution. Either go with the command-line version and write your own scripts around it, if you can. Or if you don’t have the time or inclination for that (like I don’t), look for another software, either a separate backup solution or perhaps a 3rd party management software that can decently integrate the command-line version of Duplicacy.(if such a thing exists).

Well, I think it’s way past time that I step off my soapbox. I suppose that I may ruffle some feathers here, but that’s okay. The time for gentle nudging is long over. In any case I don’t expect anything in the “product” to change for the better, but perhaps my musings will calibrate the expectation of those who have the patience to read through all of them.

Best of luck to everyone!

1 Like
#8

Duplicacy has, for some time, offered a feature to send reports to a service such as healthchecks.io - so even if backups utterly fail, you can be alerted after a customisable grace period.

For what reason are you not able to set hostname?

#9

I read the referenced post and it doesn’t sound like it would solve my problem, because the duplicacy process kept running. It was just the backup jobs that it invoke that kept terminating with an error code, so if I understand this correctly healthio would have still received notifications and assumed that everything is fine. So this is solving a different problem (Duplicacy-Web process dying) not “Backup process terminating with error”. I can see that it can be a useful feature, but it’s not my primary problem. I want the option to only receive emails when the backup jobs terminate with an error. Usually the duplicacy main process still keeps running, because when I finally logged into the web ui, it showed all those job steps in “failed” status.

#10

Oh damn, this is all really sad to read. I wasn’t aware that licencing has been a long-time issue.
When I chose Duplicacy I did because of the speed with large backup sets.

I guess I’ll have to reconsider.

Unlike Docker, in Kubernetes you are unable to set a hostname. There simply is no such option. To ensure pods can scale, a hostname with a random string at the end is beeing set automaticly.

#11

The licensing issue is part of the Duplicacy-Web UI, which is a wrapper around the engine. The engine itself is very good and available separately as command line utility (free for personal use) at github: Releases · gilbertchen/duplicacy · GitHub

So if that’s sufficient for you, then you can ditch the Web version and just use the command line version for your backups (You could still use the Web-UI to check results, run check and prune jobs, etc.). That’s an attractive proposition, if you’re willing to handle the potential extra steps associated with that.

As for me I spent money on the Web Edition specifically because I wanted a solution that “just works” and didn’t require a lot of effort to setup and maintain a backup solution that requires minimal attention and thus I could use it on my family members’ computers and it would just run.

This is where the strength of the Web Edition should be IMHO, make the whole process as smooth as possible and make Duplicacy accessible to a larger audience of more casual computer home users and perhaps small businesses with a few employees that don’t really have an IT department to spend much time on keeping things running.

And that’s why I’m so salty about the Web Edition, because - while it looks nice on the surface - it just doesn’t deliver on that expectation. And that fundamentally hasn’t changed since early 2020, when I first started using Duplicacy-Web.

#12

This is simply not accurate. Duplicacy won’t send the report if the job fails. That’s the entire point of the feature.

Case in point - I had a slight hiccup yesterday with my server losing connection (it’s a very old MicroServer, running Windows Server, soon-to-be replaced). Duplicacy was erroring on its backups:

image
image889×195 4.74 KB

(Last night, I logged off my computer and back on, backups resumed and I thought all was OK - turns out it wasn’t the client and the server itself needed a reboot.)

As you can see, this corresponds with the pings healthchecks.io registered, missing a whole chunk where the errors occurred:

image

I set a fairly generous 1 day grace period coz I occasionally tend to quit Duplicacy during an evening of FPS gaming, when it gets especially competitive.

image

image

This feature would work for both you and your family member.

#13

While I agree there can be improvements in how the licence activation is done (particularly with late renewals requiring client access; although that no longer applies to my personal lifetime licences), I’ve not had any major issues with other (commercial) activations and nor do I believe anyone not running macOS…

There’s been a handful of reports from macOS users where the hostname doesn’t match, due to Duplicacy or the OS using a capitalised version of the name instead. (Can’t find the post.) This certainly needs investigating and fixed for those users, but the problem isn’t universal.

I’m not familiar with Kubernetes but that sounds like it would be a massive oversight not to allow hostnames to be set outside the pod (either manually or systematically).

Are you saying you can’t set hostname in your particular setup?

image
image1046×65 2.69 KB

#14

The hostname check isn’t the primary reason for licensing issues. Rather, it is often due to a change in the hardware ID, which makes the server fail to match the license to the previously assigned computer.

I think the solution is to include the activation code in the license so that our license server can always look up the license by the activation code. Currently most licensing issues can be fixed by reentering the activation code so if the license code were available then this step could have been done automatically.

I’ll make this change for the upcoming new release.

1 Like
Duplicacy Web Edition 1.7.2 releases
#15

This was fixed a while ago. The hostname check is now case-insenstive.

1 Like
#16

Would this change let remote Duplicacy clients reactivate themselves after a late licence renewal? Coz that would be nice to have.

Good to know. Duplicacy Web really would benefit from a check for updates feature. (Not an auto update, just a simple check, subtly change the tray icon, and link to the download page.)

#17

That is actually a separate issue but yes, I’ll fix that as well.

2 Likes
#18

I’m testing this out at the moment, but it looks more promising than I thought. Unfortunatel though it appears already that the current implementation is not sufficient for my needs:

  • The check URL is configured on the per “Backup”, so it seems to only apply to backup job steps when running a schedule. In my own case however I run the backup job step to a local destination and then use two copy steps to push them out to the remote repositories. So an error during a copy step ( as well as potential errors during “prune” and “check” steps, if that’s a thing) won’t be caught by the current implementation (though it will catch licensing problems of course).

Instead this feature should be implemented on the level of the schedule in the following manner: It’s only a success, if all job steps succeed, an error in one or more steps is considered a failure. That way problems with copy, check and prune steps would be caught as well.

The option “Send report on failure” doesn’t work properly and its current implementation doesn’t make any sense:

  • It doesn’t work properly: When the option is checked, a failure in the backup job will trigger the URL send, but a license key failure will not (presumably because that is happening before the backup job ever gets invoked).

  • It doesn’t make sense, because there’s no point in sending the same URL when an error occurs. Instead of that checkbox there should be a second field “URL upon error” (and the first field could be renamed from “URL” to “URL upon success”). When a failure occurs, the system would invoke the “URL upon failure”, if it’s there or do nothing, if the field is empty.That would work nicesly with the current options that healthchecks.io provides ( see Signaling failures - Healthchecks.io ) as it would allow you to get failure notifications in a timely manner and you wouldn’t have to rely on any grace period.

Of course then the failure URL would also need to be invoked, if the license check fails, or if any other problems prevents the execution of the job.

In my family member’s case, I never know how often she uses her computer, so I’d need to set an extremely generous grace period with healthchecks io (maybe two to three weeks, in case she’s travelling), but I could receiver alerts about active job failures immediately.

So in summary:

  1. Put the configuration option “Send backup report to” on a job schedule and interpret a success as “all job steps finished without an error”
  2. Replace the option “Send report on failure” with a field “URL upon error”
  3. If set, invoke the “URL up error” also when a failure occurs before a job is ever invoked (e.g. license key check)

As said #1 would be essential for myself to ensure remote copy (and check and prune jobs) are monitored as well, Fixing #2 would only be important, if #3 is implemented. Both together would be helpful to monitor systems where the backup frequency is unpredictable (my family member’s Mac) and it would be useful to receive notifications of problems in a more timely manner.

#19

Is this supposed to be fixed in the latest web version? I just deployed duplicacy on TrueNAS SCALE (like OP) and I still have to manually reactivate/transfer the license to the new hostname everytime I reboot or redeploy the container. I don’t know the specifics of the hardware ID checks but I wouldn’t imagine that information would change since it’s just a container and not a new VM or physical machine.

#20

@algebro I found the only way to persist the hostname with any sort of deployment with TrueNAS Scale was to have it set to host networking, so the container/pod inherits the hostname of your machine.

Hope that helps you or anyone else who might be tearing their hair out like I was about this.