501 karma · joined September 18, 2014
Yeah, you see where this is going. The prod dump finished in time and shortly before leaving work I started importing the data. Then I sat around for a while before I realized I had forgotten about that additional "use the test environment" parameter -- and now I was importing a several hours old dump into the production database while the daily production run was running. I had to call company execs and explain the catastrophe to them, who in turn had to call in the vendor that sold us the system. Those were some pretty scary hours for a 20 yr old kid. Luckily it was just a matter of aborting the production run, reload the prod dump and then reschedule the production run for the day.
The next day I had to start my day at the vendor's place to get some shaming, but also a good piece of advice - "always say destructive things out loud before doing them". Then they continued to tell me stories of people they had worked with who really messed things up, and we all had some good, evil laughs.
Mistakes build experience, and hard learned lessons even more so. You now have a pretty good conversation starter to put on your CV. Personally I'd rather hire someone who was a "removal" specialist over someone who hadn't learned the skill yet. :)
I believe both GitLab and the community in general will come out stronger from this incident. Thank you all for being so transparent about it.
To deploy code with Salt, we had an SSH account on the Salt server configured with a bunch of deploy keys. Each of those had a forced command that would read $SSH_ORIGINAL_COMMAND and forward this information to an agent (running as root) that would execute Salt with the correct arguments, based on information in $SSH_ORIGINAL_COMMAND. This let us use a build step in TeamCity that basically did ssh deploy@mgmt-gateway [env] [project] [version]. Deployments were logged to New Relic and Slack.
In a different team that are fond of PHP we use a private GitLab CE for code management, GitLab CI Multi-runner as the build agent for CI/CD, Ansible for configuration management and code deploys to different environments running on AWS EC2. Like in the previous team, we have configured our .gitlab-ci.yml to pass some arguments in $SSH_ORIGINAL_COMMAND over SSH to a management node that in turns talks to Ansible.
Something I like with having a private GitLab CE instance is that development doesn't stop because your public Git host is DDoSed or have other problems (like the recently discussed one here on HN).
Test and staging servers are shutdown/destroyed off-hours and restarted/recreated by cron jobs that execute Ansible plays which identify eligible EC2 instances via EC2 tags. Production environments with multiple servers are similarly scaled down during off-hours. By simply modifying/removing the "shutdown" tag from the AWS resources, teams are able to exclude their test/staging environments from the scheduled shutdowns, something which is useful for upcoming releases. ;)
In the Node/Golang shop I loved how simple Docker images were and how good it felt to deploy it to isolated containers. Unfortunately, I don't see how that's possible (in a clean way, preferrably without using two images) when both an Nginx process (static file serving, e.g. frontend resources) and a PHP-FPM process needs access to the same code release.
(If you have experience with Nginx/PHP-FPM apps and Docker, feel free to enlighten me!)
Things I'm not entirely fond of about GitLab CI is that:
- each branch in each repo must have a .gitlab-ci.yml that is up-to-date (administrative challenge!)
- it's entirely driven from a git push (though the web gui provides buttons for existing builds to retry/manually execute steps to e.g. deploy code)
GitLab has no support for a centrally managed .gitlab-ci.yml file on a project group and/or project level. There's no way to define variables on a project group and/or project level. There's no way to schedule jobs so that you can execute daily/weekly tests, or to manage jobs (in a user-friendly way via the web gui) that perform cron-like tasks, so you can avoid putting these tasks on the server themselves in /etc/cron.d (which becomes a problem when you restore backups / bake AMIs / do auto-scaling).
I'd love to look more into K8 and Google's cloud offerings, especially since I believe this might be the future and because I believe Google are lightyears ahead of the competition when it comes to security and protecting the privacy of its customers. Unfortunately I'm afraid it's not viable given my team's current investment in Nginx/PHP-FPM apps and various AWS services.
PS. SSL Labs gives your site an F grade due to CVE-2016-2107.
Currently dual booting it on one MBA11" 2012 and one MBA13" 2014 (wifi via the proprietary wl driver).
Are there any good alternatives available on Linux?
We've implemented 802.1x with dynamic vlan assignment already, meaning that when a user connects either wired or wirelessly they get shunted into the appropriate segment of the network (and potentially into overlapping subnets). This ensures strong segregation based on their identity/certificate. So we really want to plug openvpn into that and allow users a single certificate to always end up in their same segregated section of the network without having to create separate VPN subnets for them.
TLDR: These patches allow OpenVPN to be used in enterprise environments with RADIUS authentication and dynamic VLAN assignments.
Coming from a previous job where we used GitHub and TeamCity, something I miss with GitLab is the ability to create a pipeline that's not connected to a specific Git branch. I'd like to be able to create a pipeline that can be triggered manually, without first having to create a dummy branch to put a .gitlab-ci.yml there. Is that something that's on your roadmap?
As usual the rest of the world is not a place within the US. It's a shame some people keep overlooking that.
Quote: SkyJack (available from github) is primarily a perl application which runs off of a Linux machine, runs aircrack-ng in order to get its wifi card into monitor mode, detects all wireless networks and clients around, deactivates any clients connected to Parrot AR.drones, connects to the now free Parrot AR.Drone as its owner, then uses node.js with node-ar-drone to control zombie drones.
There is also some info/links regarding DJI's Phantom line of drones on https://github.com/noahwilliamsson/dji-phantom-vision
Quote: The Range Extender is essentially a small Linux system based on OpenWRT which provides a WiFi-network used by the Phantom and the DJI Vision App. It's reachable over SSH at 192.168.1.2 (root / 19881209). The WiFi-network has no security by default and neither the Phantom nor the DJI Vision app supports password protecting it. Additionally, it is required that the network name is prefixed with "Phantom_" in order for the Phantom to find and associate with it.
I recall there was a Swede (the grue?) on the Pull the Plug IRC network who was cross-compiling and linking in backdoored object code in Cisco IOS images already back in 2000.
The mainframe logs show that a dataset containing a copy of the Schengen SIS was downloaded from the hacked mainframe. I don't know if the file was even found on mr Svartholm's computer. The prosecutors just concluded that they couldn't tell what happened with the datat that had been copied out from the system and therefore mr Svartholm probably did something evil with it.
So what's in Schengen SIS? It's a list of personal details for more than 1 million(!!) people that are either wanted by participating states, under surveillance or people that just lost their passports or other identity documents. You can read more here: https://en.wikipedia.org/wiki/Schengen_Information_System#Da...
The government of course would like to claim that the data managed in Schengen SIS is extremly sensitive. Meanwhile they ship this data over the internet with plaintext FTP to various entities participating in Schengen SIS on a monthly basis (updates etc).
>> In a separate trial in 2013, Mr Warg and accomplice were found guilty of breaking into the computer systems of computer services firm Logica, which was doing work for Sweden's tax office and a bank. > Again, why would he hack into a bank knowing so many eyes are on him?
He was completely acquitted of the charges involving Nordea Bank in the Court of Appeals (Hovratten).
I've seen a few commenters here on HN that point out that pretty much everything since Windows XP (ignoring IE6) supports at least 1.0 of the TLS protocols. While that may be correct in theory, in practice it's not.
At a 1MM+ visitors/week site we still see a few percent of our users that regularly connect using SSLv3 across different versions of Windows, including more modern ones such as Windows Vista, 7 and 8(!)
Though I'm not sure why this is the case, antivirus software suites such as McAfee[1] have in the past been known to disable TLS 1.0 system wide in Windows.
[1] http://answers.microsoft.com/en-us/ie/forum/ie8-windows_othe...