| { | |
| "title": "&yet", | |
| "services": { | |
| "query": { | |
| "idQueue": [ | |
| 1, | |
| 2, | |
| 3, | |
| 4 | |
| ], |
| log_format logstash_json '{ "@timestamp": "$time_iso8601", ' | |
| '"@source": "$server_addr", ' | |
| '"@fields": { ' | |
| '"domain": "$host", ' | |
| '"url": "$uri", ' | |
| '"client": "$remote_addr", ' | |
| '"user": "$remote_user", ' | |
| '"size": "$body_bytes_sent", ' | |
| '"responsetime": "$request_time", ' | |
| '"upstreamtime": "$upstream_response_time", ' |
| runit uses a directory structure along the lines of: | |
| /etc/sv/<appname>/ | |
| env/ | |
| log/ | |
| and in the <appname> dir it expects to find a "run" bash script - for this example the node app has been installed in /home/myapp/mynodeapp/ where "myapp" is the user to run the app under and is started by "node server.js". | |
| environment vars are stored as files inside of /etc/sv/<appname>/env/ |
| I've seen a few recent tips and tricks being published about how to store deploy secrets, such as configuration items, keys and other things you normally don't want public, in the same repo as the other parts of a deploy stack and thought I would make a quick post about why I think it's a bad idea. | |
| The first issue that came to mind was that a simple mistake made in setting up your git environment and you could accidentally clear-post without realizing it. Sure the data is stored encrypted and you would need to checkout using the key, but how many times have you copied whole directories over from one project to another using the command line. | |
| Another is about how encrypted text is attacked. Analysis is done of the encrypted text over time and now you have just given an attacker a known history of all changes. | |
| But for me the real reason is part tech and part social engineering - usage of secret data should have a separate method of retrieval that makes you think about the fact that you are pulling secret dat |
| from Queue import Empty | |
| from multiprocessing import Process, Queue | |
| def handlerOne(inbound): | |
| while True: | |
| try: | |
| key, item = inbound.get(False) | |
| if item is not None: |
| losa | |
| small loosely coupled teams | |
| self directing | |
| code reviews |
In a perfect world, where things are done well, not just quickly, I would expect to find the following when joining the company:
Documentation
Accurate / up-to-date systems architecture diagram
Accurate / up-to-date network diagram
Out-of-hours support plan
Incident management plan
| The latest security issue with Rails is a cause for worry IMO - if you are running any rails app please check. | |
| tl;dr (pulled from the article linked below) | |
| * Threat Agents: Anyone who is able to make HTTPs request to your Rails application. | |
| * Exploitability: Easy — Proof of concepts in the wild require only the URL of the application to attack a Ruby code payload. | |
| * Prevalence: Widespread — All Rails versions prior to those released on Tuesday are vulnerable. | |
| * Detectability: Easy — No special knowledge of the application is required to test it for the vulnerability, making it simple to perform automated spray-and-pray scans. | |
| * Technical Impacts: Severe — Attackers can execute Ruby (and therefore shell) code at the privilege level of the application process, potentially leading to host takeover. | |
| * Business Impacts: Severe — All of your data could be stolen and your server resources could be used for malicious purposes. Consider the reputation damage from these impacts. |
| import twitter | |
| api = twitter.Api(consumer_key='consumerKey', | |
| consumer_secret='consumerSecret', | |
| access_token_key='accessKey', | |
| access_token_secret='accessSecret', | |
| debugHTTP=False) | |
| timeline = api.GetFriendsTimeline(since_id=sinceid, retweets=True, include_entities=True) |
| #!/bin/bash | |
| # | |
| # Distributed downloading script for fileplanet | |
| # (shamelessly copied from the Mobile-Me project) | |
| # | |
| # Usage: | |
| # ./seesaw_fp.sh $YOURNICK $start $end | |
| # | |
| # To stop the script gracefully, touch STOP in the script's |