3 ms·
Awesome, thanks! We definitely offer trial versions to install on-prem with a built-in permanent 10-server license (via a one-liner), and we provide 30 (and som
by jamiesonbecker 9y ago
Awesome, thanks! We definitely offer trial versions to install on-prem with a built-in permanent 10-server license (via a one-liner), and we provide 30 (and sometimes 60) day free trials for however many servers you need for anyone who asks. Converting to production is just a matter of pasting a new key. We could probably make this a bit more clear on our website though (it's buried in our docs section[1])
That is a good point and that doc page is really incomplete. Upgrades are completely automatic in Userify, and without diving too deep into the `curl https | sh` debate :), security conscious are always well advised to do the regular curl > file.sh anyway, even with CA cert checks. Just a good idea.
1. https://userify.com/docs/enterprise/installation/ https://userify.com/docs/enterprise/installation/
- solatic 9y ago> without diving too deep into the `curl https | sh` debate :) So now that it's clear to me that it is possible to do an on-prem install, I decided to look at your curl->sh install script. You guys are basically justifying the fears of our security folks. After grabbing sudo from the user, without asking permission, you pkill NTPD (!), add pool.ntp.org (never mind that we may run our own NTP servers, specifically to remove Internet-based dependencies to lower risk...) and start NTPD again, invoke an install-pip script from a server you don't control (https://bootstrap.pypa.io/get-pip.py https://bootstrap.pypa.io/get-pip.py) without attempting to see if maybe there's a local package of pip available, and then install the EPEL repository. Which is, you know, a perfectly fine repository, but there's a reason why the software included in it isn't included with the official Red Hat repositories and so adding the EPEL repository without asking permission to do so can wreak serious havoc on servers with auto-update scripts installed with the intent to only grab security fixes for installed software. Why can't you guys just open-source some real packaging and respect the sysadmins who you want to be your customers? > Upgrades are completely automatic in Userify Most enterprises who are paying sysadmins to manage their server environments do so at least in part because they want their sysadmins to, you know, manage their server environments, like not upgrading services during peak usage (cough, Windows 10, cough). I'm not saying I won't still try out Userify... I'm saying that, when one of my chief complaints about Atlassian was a lack of packaging support, you came in to champion a product that not only doesn't provide packaging support, but reminds me why packaging support is necessary. If Userify meets our needs, we'll end up needing to package it internally, which means it has to go on our priority list somewhere, and probably not near the top. Sorry if this sounds harsh... just trying to keep it real.
- jamiesonbecker 9y agoHi Solatic, no problem and appreciate your direct approach :) Pull requests are gratefully accepted: https://github.com/userify/userify-server-tools https://github.com/userify/userify-server-tools Why don't you discuss with one of our solutions architects (or me) by email instead? Most enterprises definitely do package for their unique environment, and we certainly will assist. My email is jamieson.becker@.
- semperdark 9y agoYou're making him go through an awful lot of trouble to be a customer. This sounds like you're telling him to stop talking about his concerns so loudly (in public) rather than actually looking into them.
- jamiesonbecker 9y agoSorry, didn't mean to make it sound like that! Just didn't want to stray too far OT. But I meant what I said.. we work with a lot of larger companies that need to integrate Userify into docker, ansible, terraform, chef, cloudformation, etc. There's so many different ways that people prefer to manage their systems that we don't want to push a single One True Way(tm). We instead try to cover 80% of the use cases with a simple script that can be deployed in a typical cloud scenario which is open sourced at github -- and then customers can customize when necessary or even provide pull reqs back if their customizations are generally applicable. Some of the parent's complaints are themselves a result of issues that customers have run into, and if this buried in an RPM, it'd be a lot less transparent on what it does and how it works. For example, we force a pip upgrade, because the version that's built into RHEL6 is too old and can't build cryptography, etc. We also don't forcibly add pool.ntp.org -- we run ntpdate against it to get a quick clock set. We have to add EPEL because RHEL6 and RHEL7 don't provide Redis in their own repos. This is designed to be run, as the docs clearly state, on a clean RHEL7+ or Ubuntu 16+ instance with defaults. How you customize it, either before or after, is entirely up to you. Anyway, Userify is certainly not for everyone. A lot of people still prefer to manage their keys with shell scripts or Chef or something, which usually works great for small teams with flat perm structures. Sorry for sidetracking the discussion about Atlassian. Even though we don't use their software, I'm a big fan of their success story. Mike Cannon-Brooke's deck on how they scaled Atlassian from $10k on a credit card is really quite awesome.. I can't seem to find the video of him presenting it at a conference, but the deck alone is great: https://www.slideshare.net/mcannonbrookes/scaling-atlassian-march-2008 https://www.slideshare.net/mcannonbrookes/scaling-atlassian-...