Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 3 subscribers
  • Views 752 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Astaro Problemmanagement

Markus_Hahn
Some of you might remember that with the introduction of the Update to ASG 6.303 some problems came up. Astaro immediately released a new 303 Version which did not show these problems. You will find some Threads about this on this board.
What I want to write about is how unhappy I was with the problem management of Astaro in this case.
- There was no notification on the Astaro webpage.
- My supplier's phone was busy all day, because people constantly rang him up as they had the same problems like me.
- Astaro did not release any official document with instructions how to fix this. The only hint could be found on this board, but only understandable to Linux freaks (which I'm not).

I always was very satisfied with Astaro and their product, but this was more then unprofessional. Errors happen, that's live. But I think that Astaro in this case should have:
- published a document on how to fix the problem caused by the faulty 303 update
- or publish a document giving instructions on how to enable ASG to gather the correct 303 and install it
- or release a 304 version which would do everything automatically.

I know that one reason for the good price of the ASG is that most of the support is handeled by this board, but this issue cost me a lot of time and nerves.
A functionality to undo updates or to chose which updates are installed and which are not would have been very helpful here.


This thread was automatically locked due to age.
Parents
  • 0
    I understand your issues there.. I too agree that a simple re-release under a version number, say, 6.304 would have been the simplest way to go, with a short blurb on their website saying to install this if you are having issues with PPTP.  That said, all my customers (we are a reseller) wait for me to send out an email on system up2dates, as we test them in our production and lab environments first, and roll them out to a few key locations.. after that, we send out a courtesy email to our customers (whether they are on contract with us or not) about the Up2Date.  We did find the issues with PPTP in advance; thus none of our customers were adversely affected by the buggy "first" version of 6.303.
  • 0 in reply to BrucekConvergent
    Honestly, we should all know not to install an update of any product as soon as it is released unless it is fixing a bug we need ASAP (Like the multiple email issue). Although it may have been an issue with Astaro in this case, we should all be much smarter and wait a few days if you are in a production environment.
  • 0 in reply to Keith_M
    End users should not have to edit the underlying Linux configuration files in order to keep their ASG box working. I had to edit the number in the version file back to 6.302 in order to get the a reload of the updated patch. Anyone who had their up2date patch checking set to hourly or daily, would have received the initial, flawed release of the 6.303 patch. Delaying the actual installation of the patch still left them with the same problem. I agree that it would have been much better if Astaro had quickly released a 6.304 patch with the fix in it, instead of doctoring the 6.303 patch after it had already been released.

    We can only hope that Astaro's software team learned something from this fiasco, and will approach the issue of a flawed patch release more professionally in the future.
  • 0 in reply to VelvetFog
    However, with the way Astaro patch distribution works, by downloading the patches automatically, the bad version of the 6.303 patch would still have been sitting on our ASG box as a time bomb waiting to be installed, even if we had delayed the actual installation.


    Actually, this is technically incorrect.. if your ASG prefetched the original "bad" 6.303 up2date, and you didn't install it right away, you (so long as you waited at least a day, since the prefetch occurs daily on most systems) would have had the up2date process "trash" the bad 6.303 up2date, and download the new one automatically.. something about the CRCs not matching, etc.
  • 0 in reply to VelvetFog
    I have to agree with Keith_M, that one ought to wait a bit before installing patches in a production environment. However, with the way Astaro patch distribution works, by downloading the patches automatically, the bad version of the 6.303 patch would still have been sitting on our ASG box as a time bomb waiting to be installed, even if we had delayed the actual installation.
    This is not totally correct. If Astaro re-releases a patch like they did for 6.303, the up2date process will detect that the md5sum of the downloaded file does not match the one on the servers and redownload the update.

    That said, we now have an policy to wait at least 1 week after updates are released before installation and to monitor the forums for potential issues.

    The problem of course is - if everyone does the same, it will take that much longer to find bugs and the same issue will occur!

    Edit: Bruce, you beat me by a minute. [:)]
  • 0 in reply to drees
    This is not totally correct. If Astaro re-releases a patch like they did for 6.303, the up2date process will detect that the md5sum of the downloaded file does not match the one on the servers and redownload the update.

    I know I can find it by digging through the forums, but thought I would ask.  How can you verify if you have the lastest version waiting to be updated?
  • 0 in reply to rstark
    The idea of waiting with the installation is nice and correct. BUT...
    for how long should I wait ? If everyone does so then noone will find the error, which in this case only can be found by someone installing the patch and getting into trouble. Is that particular person then unprofessional ??? I don't think so.
    Not everyone has the fonds to maintain a test enviroument which is identical to the productive in order to test new patches before applying in the productive. 
    It's not only the programmers from Astaro who should have learned their lesson. It's more the problem managers as they failed completely in this matter.
  • 0 in reply to Markus_Hahn
    One way of cheaply having a test enviroment would be to use the the virtual appliance in a sand box network using your exisiting key wouldn't it?

    I spose this would be tricky to test and actually find a bug?
  • 0 in reply to Godsbrother
    One way of cheaply having a test enviroment would be to use the the virtual appliance in a sand box network using your exisiting key wouldn't it?

    I spose this would be tricky to test and actually find a bug?

    If you get the hardware for free you are lucky. To have my astaro setup in a sand box would bw a major task, mainly financially. Even if I use my existing license keys. I have six differnet Astaro setups. Do you still think that this is tricky ?
  • 0 in reply to Markus_Hahn
    But surely the point here is its a virtual appliance so you can use any spare hardware and run any number or virtual appliances? But to be fair I only have two so its not much of an issue.
  • 0 in reply to Godsbrother
    FWIW, A VM will not help you find out that your NIC or SCSI card no longer works, etc.

    Also, it's VERY hard to simulate real-world network traffic, VPNs, worms, ...

    Barry
  • 0 in reply to BarryG
    A fair point well made. I'll shut up now [:)]
Reply Children
No Data