Jump to content

DavidHertzberg

Members
  • Content count

    1,244
  • Joined

  • Last visited

  • Days Won

    41

DavidHertzberg last won the day on July 15

DavidHertzberg had the most liked content!

Community Reputation

67 Excellent

About DavidHertzberg

  • Rank
    Occasional Forum Poster

Profile Information

  • Gender
    Male
  • Location
    New York, NY
  • Interests
    Retired applications programmer, with a few Macs at home.

Recent Profile Visitors

2,104 profile views
  1. Nigel Smith, I wrote in this up-thread post "I was proceeding to your next issue while writing this post, but I had to take an hour off and you've meanwhile beaten me to it." But IMHO your subsequent posts have not so far really "beaten me to it". That "next issue"—really three "ifs" in one long sentence, covered in this more-upthread post, was: My opinion on the first two "ifs" is based on what I wrote in the last two sentences of the first paragraph and entire second paragraph of this even-more-upthread post. It is that Remote Backup, designed for machines that don't have predictable Internet addresses, will backup any machine having the exact "backup server" Tag "Remote Backup Clients" that "reaches out" to the "backup server" with a public key that is in the "backup server"'s Remote Clients table. So long as such a "client" machine remains truly Remote, a Proactive AI script specifying "Remote Backup Clients" will back up any machine having that Tag—even if your home router's IP changes or you take the laptop to a different location. My opinion on the third "if" is based on my personal experience that Retrospect Mac 16.6's Piton Name Service will override Add Source Directly, so long as the Computer Name matches what is defined for that Source on the "backup server". So if you now now take the laptop in to work and plug in to the non-subnetted portion of your LAN, Retrospect will back it up—assuming its Computer Name is unique in the non-subnetted portion of your LAN and has not changed from when a Proactive script added it to Sources. If you've done further testing on these "ifs", please post your results.
  2. svennd, You don't say which variant of Retrospect you are using, but since you use the term "snapshot"—which has been banned for the Retrospect Mac GUI since version 8 (Engine messages still use the term, since the Engine is common code underneath the variant GUIs)—I'll assume it's Retrospect Windows. Pages 8–9 of the Retrospect Windows 17 User's Guide are a minimal description of how to generate the new Restore Preflight report for a snapshot. What it generates is a CSV, which presumably you have to import into a spreadsheet program (whatever that is; I assume one candidate is Microsoft Excel) in order to read. The front screenshot on page 8 of the Retrospect Mac 17 UG shows how to tell that variant of Retrospect 17 where to save the CSV using a macOS GUI dialog. I assume the corresponding Windows GUI dialog would be similar, but whoever in Retrospect Product Management wrote the "What's New" chapter of the Retrospect Windows 17 UG seems to have felt it was more important to show a screenshot of how to generate the CSV—owing to the crufty old GUI of Retrospect Windows (guess which variant I use 🤣 ).
  3. DavidHertzberg

    Retrospect Management Console

    Nigel Smith and anybody else, Here's a March 2020 article titled "How to Set up an iPhone VPN"; if you don't want to use a VPN app, look at the section "Manually Configure a VPN on iOS". I don't have any kind of "smart phone"—much less an iPhone—so I haven't tested out the procedure. Malcolm McLeary and anybody else, I had written an e-mail to the head of North America Sales, asking whether my temporary solution to the security hole in the Retrospect Management Console—that you had identified—would work. When I didn't get a reply I followed up with a phone call voice mail, to which he replied late Friday afternoon. He said he'd just come out of a meeting, and mentioned that there's now a supply chain problem for Drobo devices (I think we can guess where those are manufactured 🙂). I don't know how that'll affect the StorCentric-dictated priorities mentioned in the last sentence of this post in another thread; i.e. whether it'll permit diverting engineers to fixing the Retrospect Management Console problems discussed in this thread sooner or not. I didn't want to interrogate the head of North America Sales on whether this Retrospect Management Console answer will work; after all, I'd be asking a salesperson whether there's an additional feature available at no charge—without paying for the Management Console Add-on. So after a couple of days I tried it this morning; it seemed to work using a Retrospect Mac 16.6 "backup server"—but see the P.S. on Sales "helpfully" giving me the Add-On license. On my MacBook Pro "client" I executed the "Account Creation" procedure in this document, using my regular e-mail password and the Forums password it defaulted to. When I got the confirmation e-mail I clicked the Confirm Account link and assiged an organization name. I copied the UUID from the dialog onto a piece of paper, walked 45 feet to my Mac Pro "backup server", booted it and immediately paused all Retrospect activities, and followed the "System Setup" procedure's "Retrospect Backup" sub-section in the document—copying the UUID from the piece of paper. I then un-paused all activities, went to my MBP's Firefox browser, and opened a tab with the URL https://console.retrospect.com/dashboard?—which inserted the machine= and organization= fields at the end of the URL. I then clicked the name of my "backup server" in the left-hand column, and got a Dashboard delayed behind the actual "backup server" by 2 to 4 minutes. I guess that's the Heroku updating lag—RMC 's price you pay for not having to VPN into each site separately. I can log out the Management Console from my MBP, close the tab, and re-open it again with the the same URL—which on my MBP fills in the remaining fields. When I then click the Log In button on the top right of the Web page, entering the e-mail address I used for Account Creation and putting in the password—with no 2FA—gets me to a Dashboard panel. Above the Dashboard are additional buttons for Past Activities, Sources, Sets, and Scripts; clicking one switches to an appropriate panel. However this enables the security flaw Malcolm McLeary has identified—see the P.S. for why. Clicking the Scripts button gives me a panel with a New Script button on the top right; clicking that appears to enable me to create a new Proactive Script 🙄. Therefore I intend to disable Management Console on my Mac Pro's Retrospect Preferences, since I have no need for it so long as I can walk 45 feet. P.S.: A possible reason the security flaw is still present is explained in an e-mail I got yesterday afternoon from another Retrospect Inc. salesperson just as I was leaving for an appointment. It said he had given me a Retrospect Management Console Add-On license for free, apparently because my posting activity on these Forums—for which I'm not paid—is considered helpful for Sales. The e-mail apologized because the Add-On license might not have worked; when I returned home I hurriedly phoned back and asked the salesperson to remove the Add-On license, which I had intentionally never asked for. P.P.S.: That Sales e-mail requested I re-sign-up for a Management Console, which I did this afternoon using a different e-mail address. That Management Console had—as I hoped—only a functioning Dashboard the first time I logged-in, but later logins give it access to Scripts and the ability to create a new flawed script. (Possibly the "gift" Management Console Add-On license applies to my "backup server", not the RMC itself; I'll check by phone later today.) AFAICT I don’t have Remote Granular Management or Shared Scripts, which are Add-On features. P.P.P.S: This morning's No Media Action backup of my MacBook Pro—while running and afterward—displayed Past Activities, Sources, Sets, and Scripts on RMC using my newer e-mail address—so the "backup server" security flaw still exists for the RMC . That means my temporary solution doesn't work, so Malcolm McLeary should pursue a permanent solution—2FA or "Backup Sets Must Be Encrypted" preference. BTW naming of backed-up drives in segments on RMC Backup Report and Backups bar chart panes is erroneous, as it is on my Retrospect Mac 16.6 Dashboard panel—with different errors.
  4. Nigel Smith, Notice that I rewrote my two preceding posts in this thread, here and here, to explain what I think is going on with Remote Backup in light of your tests. Everybody, I had written an e-mail to the head of North America Sales, asking whether my temporary solution to the security hole in the Retrospect Management Console that Malcolm McLeary had identified would work. When I didn't get a reply I followed up with a phone call voice mail, to which he replied late Friday afternoon. He said he had just come out of a meeting, and mentioned that there is now a supply chain problem for Drobo devices (I think we can guess where those are manufactured). I don't know how that will affect the StorCentric-dictated priorities mentioned in the last sentence of my immediately-above post; i.e. whether it will allow the engineers to divert to fixing the Retrospect Mac problems discussed in this thread sooner or not.
  5. DavidHertzberg

    Tag selection whack-a-mole

    eeolson, I'm not one of your followers; I merely looked at your past posts in your Forums profile by clicking on your name. The underlying code for the "backup server" Engines of Retrospect Windows and Retrospect Mac has been the same since late 2009. The "stagnation" between Retrospect Windows 7.7 and 17 was only in the UI, which has been kept the same partly because of the bad reputation for reliability and temporary hardware compatibility restrictions of Retrospect Mac 8 (which was developed in a hurry after EMC reversed an end-of-lifing of the product)—but mostly because of a Windows limitation described in the second paragraph of the Wikipedia article section here. Retrospect Mac 9 fixed the problems in Retrospect Mac 8; this immediately-preceding WP article section describes its enhancements. Starting with the next WP article section is a version-by-version listing of the enhancements in the "backup server" between Retrospect Mac 10 and Retrospect Mac 14, which correspond to those of Retrospect Windows 8 through Retrospect Windows 12. Retrospect 15 (whose Windows version number was bumped from 13, in order to restore version number parity with Retrospect Mac 15) enhancements included e-mail protection, what is now called ProactiveAI, Remote Backup, data hooks, and the beta of the Management Console. Retrospect 16 enhancements included Storage Groups, deployment tools, and the features of the Management Console Add-On. Retrospect 17 enhancements include Automated Onboarding for the Management Console, speeded-up ProactiveAI, and Restore Preflight. In short, versions of Retrospect Mac beyond 8 exceed (green flags) just "patches that are packaged and sold as expensive upgrades". After using Retrospect Mac from 1995 to 2010—ending with Retrospect Mac 6, I started again using Retrospect Mac 12 in 2015—following a five-year hiatus caused by the death from old age of my ancient "backup server" machine (whose PowerPC hardware was incompatible with Retrospect Mac 8). As I said in the second paragraph of my post directly below your OP, I'm still using Retrospect Mac 16.6—because I don't need the new features or bug fixes so far introduced with Retrospect Mac 17. Nobody else on these Forums has reported a bug with the stickyness of Tag checkmarks. Some administrators—including me starting with Retrospect Mac 14—have had problems with -530 errors on client access, but I discovered a couple of years ago that I could eliminate those errors by using the “Add Source Directly” button at the bottom of the Sources->Add dialog (item 6 on page 74 of the Retrospect Mac 17 User's Guide). In response to my Support Case, Retrospect Tech Support has agreed that my submitted logs show a problem—caused IMHO by macOS/hardware changes that affect the Piton Name Service's use of Multicast—which the engineers haven't yet been able to isolate. What you describe for for your Proactive scripts sounds like a problem that was supposed to be fixed by the "ProactiveAI" enhancement in Retrospect 15. Precisely what version of Retrospect Mac are you using—not just for the Clients but for the "backup server"? Maybe your "backup server" is still running Retrospect Mac 12 (click "About Retrospect" in the "Retrospect" menu), because you're convinced you don't need to spend money upgrading. 😒
  6. (The disclaimer at the top of this post in another thread applies here.) Nigel Smith (the Forums ate my previous version of this post early this morning), When I said "sloppily written section of a KB article", it was with full awareness that from 2015–2020 the "official" documentation for Retrospect features was written by engineers as a series of Knowledge Base articles—some of which were in March 2020 copied as Appendixes to the User's Guides, IMHO partly because Retrospect Inc. could no longer afford to hire a tech writer to update the UGs. That full awareness extends to the notorious decades-long inadequacies of the engineers' alpha-testing that extends all the way back to the Dantz days (read the next page of Ars Technica 2016 Retrospect thread posts following this one). So I'm pretty sure that the engineer who wrote the KB article on Remote Backup alpha-tested his own kludgy feature by taking a machine that had already been backed up as one of a "backup server"'s Sources and having it connect remotely to a Proactive script. Sloppy test + doc. The foundation of the kludginess you've now encountered starts with the Automatically Add Clients option. Maybe it used "the industry standard method of onboarding work computers that are to be used remotely" as of 2009, but it's a potential kludge. Quoting from page 72 of the Retrospect Mac 17 UG: But the kludginess comes into full flower with the Remote Backup feature, which IMHO was developed as part of the 2018 "go big or go home" strategy. You've now discovered that it introduced a contradiction. Quoting from the " Server-Side Retrospect Engine Configuration" section of the 2018 KB article: In your testing, the running Proactive script created an ugly Add of a new Source before the running Engine was able to Automatically Add. Lucky you, 🤣 you get to write the Support Case—copying your posts above—because I can't repeat those experiments in my diminutive installation. If I were Emmanuel Macron, I'd award you the Croix de Guerre; if I were J. G. Heithcock, I'd be disturbed you found this contradiction. But the priorities of StorCentric—which wants a Drobo "backup server" (that post's 2nd long paragraph)—now over-rule those of Heithcock; don't expect the contradiction to be fixed this year.😎
  7. I don't think you read my preceding post thoroughly enough, Nigel Smith; perhaps I wrote it without enough concrete examples. Your scheme would work for RecentlyRemote "client" machines, but not for AlwaysRemote "client" machines. That's because there's no "client record" on the "backup server" for an AlwaysRemote "client" machine. It seems the Automatically Add Clients option will cause a Proactive script to create one, but not one that you like. Here's a couple of contrived concrete examples: Let's first say that I am a PhD Student at the academic institution where you are the backup administrator, and I initially do my research using an on-campus machine that was set up for me. You Added my machine to Sources, so it has a "client record" on the "backup server". Then the COVID-19 pandemic arrives, and you tell me to take my machine and go back to my home somewhere off-campus—where it will have an Internet address that's not on the institution's LAN. That makes my machine a RecentlyRemote "client" which you are still going to backup on your "backup server". Now let's instead say that I have been granted some kind of External PhD Student status, which says that I can do all my research remotely without ever having set foot on your campus. (Maybe I was originally admitted as a regular PhD Student, but I now can't be allowed in Great Britain because I come from the pandemic-ridden U. S..) I'm to use my personal machine for research, and you want to back up the research centrally, but you can't Add it to Sources because there's no way to connect it to the LAN. So there's no "client record" for my machine on the "backup server"—unless a Proactive script creates one per Automatically Add Clients; that makes it an AlwaysRemote "client". This is the original use case for Remote Backup, which IMHO was introduced in 2018 to back up the machines of hired-locally sales or support people; those people would receive all their institutional training via books or Internet, and would obtain their own machines in whatever country they were stationed—such as Sally in Shanghai or Albert in Adelaide. Presumably Retrospect Product Management determined that there were enough customers with such AlwaysRemote staff members that it was worth developing the original Remote Backup feature. Therefore I propose a scheme that will keep the AlwaysRemote capability while adding a RecentlyRemote capability, but introducing a "user-defined matching attribute" that will allow a "member of the class" of Remote tags to be used to specify whether a RecentlyRemote or AlwaysRemote machine should be backed up by a particular Proactive script. I was proceeding to your next issue while writing this post, but I had to take an hour off and you've meanwhile beaten me to it. As for where you said I was wrong, you quoted a sloppily-written section of a KB article. If you read that section carefully, you'll see that its "for instance" assumes that the "client" was first given "the initial full backup on the local network". That would make it by my definition a RecentlyRemote machine, not an AlwaysRemote machine.
  8. I don't see how your scheme could apply different "Remote Backup Clients"-derived tags to different "client" machines, and later have a Proactive script recognize which tag should be associated with a particular "client" sending a "back me up" message to the "backup server", without initially having had that "client" machine on the same LAN as the "backup server". You'd want this to happen so that a particular Proactive script could say "my sources include some Remote Backup Clients, but not this one, so I won't even scan it". You pointed out up-thread that a Rule won't avoid scan + snapshot time. The reason your scheme would need to initially have each potentially-Remote "client" machine on the "backup server"'s LAN is that Retrospect provides no other way of defining a machine as a source. That Sources->Add would at a minimum have to capture the machine's Computer Name, because the machine's later "back me up" message would have to include the sender's Computer Name to allow a Proactive script to determine whether its list of "Remote Backup Clients"-derived tags applied to the sender. The "client" machine's name would have to be unique on that LAN, although it might only have to be unique to a subnet of the LAN if the machine's Retrospect Client stored—and later transmitted with the Computer Name—the subnet name. It's also not possible to define a Favorite Folder—or an added drive—on a machine that isn't connected to the LAN. (I've checked this out by shutting down the "client" on which I've drafted this post.) However you can add or remove a tag for a defined source. You were able to define Favorite Folders—on their existing drives—for your own laptops because you'd brought them in and connected them to your "backup server"'s LAN. However I'd advise you against having PhDs/PostDocs bring in their machines for temporary LAN attachment, because that's now a good way 🙄 for you—or them—to catch COVID-19. Taking a broader view, there are two different use cases for Remote Backup. As designed by Retrospect Product Management in 2018, the use case was for AlwaysRemote (my term) machines, those that would never be put on the same LAN as the "backup server". Product Management assumed that an installation would only have a few such machines, so they probably didn't worry too much that their phantom-Tag "Remote Backup Clients" would oblige a Proactive script whose sources included that phantom-Tag to back up all machines sending the "back me up" message. However Alanna's OP in another thread was the first on these Forums to discuss the RecentlyRemote (my term) use case, in which she evidently planned to back up—as split up among different Proactive scripts—many machines that had been recently moved for Work From Home in the same time zone. As I've said in the preceding three paragraphs, that won't work with your scheme unless the RecentlyRemote machines are first brought or sent to the "backup server"'s LAN location—and unless Proactive scripts and the Retrospect Client Installer are both enhanced to store Computer Names to be included in the "back me up" messages. I think my suffix scheme would be preferable, because it handles both the AlwaysRemote and RecentlyRemote use cases. It wouldn't allow you to define Favorite Folders for AlwaysRemote machines, but neither would your scheme per two paragraphs up. Most of the code for my proposed suffix-changing utility already exists, because it's included in the version of the Retrospect Client Installer described for Management Console Automatic Onboarding.
  9. Thank you for your YouTube videos, Nigel Smith; they clarify your "production" use. They show that you first cabled the laptops to the same LAN as your "backup server", and basically followed the procedure from the bottom of page 228 to the top of page 230 in the Retrospect Mac 17 User's Guide. However they show you manually created the Tag "Remote Backup Clients" and used it to identify specific Favorite Folders on your laptops, which explains why those Favorite Folder names appear in your (topmost) screenshot of the Proactive Activity list up-thread. That's what had confused me. What you're forgetting is that Tags are only defined on a "backup server"; they don't appear on the "client" machines that they group together. As I've said up-thread, a truly remote "client" sends a message to the "backup server" whose IP address is stored in server.txt—displayed as the Public Address of its Client. Apparently the message currently says "back me up with any Proactive script; legitimized because I have this public key stored in my pubkey.dat." Page 228 of the UG doesn't explain how the "backup server" knows which backup to on-demand restore for a particular remote "client". Maybe it does so by the IP address stored by a Proactive script in Sources for a particular Remote Client backup, which would explain "Remote Backup: Fixed issue where remote backup failed if client added by name (#7705)" in the cumulative Release Notes for Retrospect Mac 15.6.1. But a remote "client"'s current IP address could have changed. In any case what's needed is a "unique identifying attribute"—as you say, but one stored in association with the Remote Client that can be combined with the Tag "Remote Backup Clients" to designate which Proactive script is to backup that particular "client" machine. I propose a suffix to the Tag, stored in association with the machine's Remote Client. There should also be a simple Retrospect utility program, which would be run by the possessor of a Remote "client" machine to either establish the suffix or to change it. If you repeated your test after the Retrospect engineers instituted use of the suffix for Remote Backup, you'd have to run the utility program to establish a suffix on each of your two laptops. If the salesperson Albert were moved from Adelaide to Beijing with his existing laptop, as described in the last paragraph of this up-thread post, he'd be told to run the utility program to change the suffix The utility would also be used if the possessor needed to acquire or replace his/her remote "client" machine without returning to headquarters; replacement examples—ripped from the headlines 🤣—would be the Shanghai PSB arresting Sally for subversion and then releasing her without her laptop, or Albert taking his laptop on a trip from Adelaide to Kangaroo Island and having it destroyed in the 2020 bushfires. Whether the suffix should be a group number or a multi-character alphanumeric string is a GUI question, although I think a multi-character alphanumeric string (may be empty) is the most administrator-friendly approach. A Proactive script would have to store the suffixes for its Remote Backup sources.
  10. Nigel Smith, You've glossed over the fact that your Proactive script "SG_Test" was evidently created before you "turned off all port forwarding on my router for this test". (Evidence is the script name, where SG stands for Storage Groups.) That IMHO is how you managed to designate Favorite Folders on "Admin's MacBook Air" and "admin2's MacBook" as sources for the script. If you can get one of your PhDs/PostDocs to temporarily install a Retrospect Client on his/her from-the-get-go Remote machine per pages 228–230 of the Retrospect Mac 17 User's Guide, and then create a Proactive script using "Remote Backup Clients" as a source, I predict you won't be able to then designate a Favorite Folder on that machine as a source in that script. All you've shown is that a Proactive script does indeed—or did as of 16.6—generate a list of clients it already has defined, and remembers that list—including possibly-obsolete IP addresses—across "backup server" restarts. Per the cumulative Release Notes for Mac 17.0.1 "Remote Backup: Fixed issue with not logging out clients after ProactiveAI backup (#7967)", your 16.6 script may not be modifying the list for Remote "clients" as it should. I can't test this for you, because I don't have any candidate Remote "clients" that I could associate with my diminutive home installation.😞 You've also glossed over the original concept of Tags: they are merely groups of drives or Favorite Folders that can be referred to in the "backup server" GUI by the same Tag name. The "Remote Backup Clients" Tag is a kludgey perversion of this concept, which needs to be enhanced by something that can be contained in a particular Retrospect Client installation—i.e. a suffix name. Just defining a "Remote Backup Clients - Group 1" to the "backup server" isn't enough; how would you define which truly-Remote "clients" that Tag refers to without particular "clients" identifying themselves as members of "Group 1", using some string associated with their installed Retrospect Client? 😕
  11. I believe I'm right, Nigel Smith. The reason is at the bottom right of your second screenshot, of "Admin's MacBook Air", where it says "Tags: Automatically Added Clients". As to what that means, here's a quote from page 72 of the Retrospect Mac 17 User's Guide, under the sub-section "Using Public/Private Key Authentication with Retrospect Clients": That identical paragraph—under the identical sub-section—is on page 63 of the Retrospect Mac 14 User's Guide, which predates the introduction of Remote Backup. So "Admin's MacBook Air"—and no doubt "admin2's MacBook"—is on what your "backup server" considers to be its network, which probably includes VPN-connected Retrospect-defined Subnets. You haven't said whether the "backup server" is at your work or home location. (However I'm sure Malcolm McLeary, our friendly Forums security guru from Australia, would thoroughly approve of your use of public/private key authentication for these "clients". ) But why didn't "Automatically add clients" just work for Remote Backup; why did the engineers need to do additional programming? Yes indeed, the Remote Backup feature introduced in Retrospect 15 is an extension of public/private key authentication. But the difference is that IMHO (I'm not a networking expert) a Retrospect Engine can't "check the network" in the same way for a Remote Client when that "network" is the entire Internet (and I'm sure the Public Security Bureau of the PRC would object to Retrospect's doing that for a "client" machine—such as the one belonging to Sally in Shanghai—that is behind the Great Firewall). That's why Retrospect Inc. added Remote Backup, in which—as it says on page 228 of the Retrospect Mac 17 UG—"When a remote client contacts the Retrospect engine for a backup [my bolding], the running ProactiveAI script [my bolding] will accept the connection and begin a backup, assuming the destination is available." This is reinforced on the same UG page, in the statement "Scheduled scripts and Immediate executions (Windows-only) are not supported because of their serialized scheduling process. ProactiveAI scripts can schedule backups for any client that is available, including remote clients." In fact the cumulative Release Notes for Mac 17.0.1 have "Remote Backup: Fixed issue with not logging out clients after ProactiveAI backup (#7967)". So "Automatically add clients" is Engine-initiated, but Remote Backup is Proactive-script-initiated. The second sentence of your next-to-last paragraph directly above is simply a restatement of my prefix solution with multi-character suffixes, such as "Group 1", allowed (unless you're proposing numeric-only suffixes with " - Group " automatically inserted, which I think would be less administrator-friendly than even single-character suffixes). OTOH the separate class of tags proposed in the last sentence of that paragraph would save administrators the trouble of typing "Remote Backup Clients" as the start of each such tag.
  12. Nigel Smith, It's the same problem; I just phrased it very badly—so badly that I've now replaced my phrasing with yours in my post directly above your post. Thanks. 😀 However I think your second paragraph directly above indicates you need to re-read the last sentence in the first paragraph and the second and third paragraphs in this up-thread post. I'm not sure you've grasped the idea that a script backing up Remote Clients can't have any pre-existing list of those "clients", because it can't know in advance—directly or by inference from unique "client" names—what their Internet addresses are going to be. Whenever it comes online, each such "client" must send a message to the "backup server" saying "back up my current IP address with any Remote Backup script you've got running that specifies the tag 'Remote Backup Clients', because I know your public key for doing that". My multiple, user-definable, Remote Backup tags solution just expands the message to say "back up my current IP address with any Remote Backup script you've got running that specifies a tag prefixed with 'Remote Backup Clients' and suffixed with a character string I'm now sending you , because I know your public key for doing that". The suffix string would be stored on the "client" in the same public_key folder containing the pubkey.dat file by the Retrospect Client installer, per pages 228–230 in the Retrospect Mac 17 User's Guide. An illustrative but tricky part of my solution would be changing the suffix string stored on a "client", as shown in the following example (which assumes single-character suffix strings): Your London-based company suddenly discovers the unexpected possibility of getting a big product order from a government agency in Beijing, and decides to rush the salesperson Albert in Adelaide there—along with his existing laptop. (For plausibility, let's further assume Albert is a Chinese-Australian with Mandarin-speaking parents, who sent him to "Sunday school" to learn to read and write Standard Chinese.) You must arrange for Albert to change the Remote Backup suffix on his laptop from 'A' (for Australia) to 'C' (for China), so that it will be backed up by the Proactive script intended to back up any of your company's Remote Backup "clients" located in China. There would have to be a Client-installer-supplementing Retrospect utility program for making that change, unless you trust Albert to find the proper file and use a text editor to change 'A' to 'C'.
  13. Excellent investigation, Nigel Smith. However, IMHO as a retired applications programmer, there's about zero chance of the engineers making any substantial change to the way Rules/Selectors are implemented—either moving them forward into the scanning phase or adding AND logic. In regard to the scanning phase, this post ending another thread (read its preceding posts if you enjoy inter-administrator arguments 🤣 ) shows the engineers sped up the scanning phase by nearly 40% in Retrospect Mac 16.0—which enabled them to abandon any attempt to make Instant Scan work with APFS-formatted volumes. (We peasants now know, which we didn't in 2018–Spring 2019, that they had to exert substantial effort in any case because Apple was about to eliminate 32-bit APIs in macOS.) IMHO the engineers are unlikely to slow down the scanning phase for all backups in order to fix an edge case for "no data" backups. I never pay attention to the Dashboard, which has had substantial bugs ever since I first encountered it in Retrospect Mac 12; that's because I know which of the 7 drives has been backed up in my diminutive home installation. In regard to adding AND logic to Rules/Selectors, the engineers haven't yet implemented the GUI enhancement to Retrospect Mac that would eliminate the problem fredturner complained about in the OP of this thread. After Mihir Shah of StorCentric finally lets them do that, IMHO they'll solve the [your re-phrase] "all Remote Backup clients are included in all Proactive/Remote scripts" problem by treating a manually-defined Tag that has the prefix "Remote Backup Clients" as indicating it is eligible for Remote Backup with a script that specifies a Tag with that prefix—as I proposed in the sixth paragraph of this post in another thread. That solution will be a lot less work for administrators to use, and it'll be a lot less programming than what you've proposed.
  14. DavidHertzberg

    Retrospect Management Console

    Malcolm McLeary, I may have found a Retrospect Management Console answer that would satisfy both your desire for monitoring backups and your desire for security with the current version of RMC. It is based on my reading of this "Feature Tiers" section of the Retrospect Management Console documentation. Per the "Features included with Management Console Add-on" sub-section of that section, script creation on an "backup server" Engine seems to require that that Engine not be an "Unmanaged Engine". AFAICT that seems to mean that if a "backup server" doesn't have a license for the Management Console Add-On , then you can't create a script to be run on it using the RMC. That would close the security hole you noticed. Of course that means that your monitoring of an "Unmanaged Engine" would be limited to the Dashboard shown at the top of this "Overview" section of the documentation. But, given that you've updated the Preferences in each "backup server" Engine with the UUID for your Management Console per the "System Setup" sub-section of the documentation, that Dashboard might be sufficient for your monitoring needs. Check with Retrospect Tech Support. P.S.: I wrote an e-mail Sunday night to the head of North America Sales, asking him to find out if my second and third paragraphs are correct.
  15. DavidHertzberg

    Retrospect Management Console

    Malcolm McLeary, (The disclaimer at the top of this up-thread post applies here.) Regarding your justified desire for 2 Factor Authentication in the Management Console, let us first consider the RMC as it currently is—an application developed by Retrospect engineers running on Heroku. Heroku currently has 2FA at the account level, but AFAICT this applies only to the developer of the application—not to a user of the application. What you want is for each authorized user of the RMC to have his/her own 2FA, and I doubt Heroku gives the capability to a developer of requiring that for a user signing in to the RMC. Maybe you could get Retrospect "Inc." to give you your own copy of the RMC application set up on Heroku's APAC server, but I doubt it. Moreover obtaining that would only enable someone with access to your "magic cellphone" containing the authenticator app to access the McLeary RMC, meaning in practice you personally. What if you want to allow a manager at your customer site to monitor his/her own site via the McLeary RMC? That argues for Retrospect "Inc." giving you authorization to install a modified version of the McLeary RMC code on a machine at each customer's site, but then you'd be responsible for making the modified version work on that particular machine. You'd also be responsible for making sure—as described under "Setting up recovery options" in the Heroku page lined to in the preceding paragraph—that either the customer knows what to do with the SMS recovery message sent to another of his/her phones that still works or that you receive that message on one your own phones. That's why the author of this recent Ars Technica front-page article thinks hardware keys are a better choice for 2FA than authenticator apps running on a smartphone. But, as the rest of that article implies, you'd be responsible for enhancing Retrospect's code for RMC to make hardware keys work on your version—depending on what particular OS it's running under. Maybe you could sell those enhancements back to Retrospect "Inc.", if they're still interested—which as I have implied in the next-to-last paragraph of this up-thread post they're probably not. Nigel Smith's suggestion to use Script Hooks to extract info from Retrospect script runs for FileMaker use would, of course, work only for scripts that have been written to use those Script Hooks. That wouldn't apply to any unauthorized scripts written by a hacker (but without RMC these couldn't exist). P.S.: My implied point in the preceding paragraph—whose last sentence I've clarified with a parenthesized clause—was that for security reasons you'd still have to eliminate any use of Heroku-hosted RMC as it exists now. A simpler monitoring solution would be to use Retrospect for iOS, if the engineers got that working again in Retrospect Windows 17.
×