| #!/bin/bash | |
| /usr/bin/certbot renew | |
| if /usr/bin/test $(find /etc/letsencrypt/live/weechat.example.com/cert.pem -mmin -60) | |
| then | |
| /bin/cat /etc/letsencrypt/live/weechat.example.com/cert.pem /etc/letsencrypt/live/weechat.example.com/privkey.pem > /home/user/.weechat/ssl/weechat.example.com_ssl.pem | |
| /bin/cat /etc/letsencrypt/live/weechat.example.com/fullchain.pem > /home/user/.weechat/ssl/weechat.example.com_fullchain.pem | |
| /usr/bin/su -c 'echo "*/relay sslcertkey" > /home/user/.weechat/weechat_fifo_*' user | |
| fi |
| // callback from indieauth | |
| $home = "http://example.org"; | |
| $fields = array("code"=>$_GET["token"], | |
| "redirect_uri" => $home."/auth.php"); | |
| $ch = curl_init(); | |
| $indieauth = "https://indieauth.com/auth"; | |
| curl_setopt($ch,CURLOPT_URL, $indieauth); | |
| curl_setopt($ch,CURLOPT_POST, True); | |
| curl_setopt($ch,CURLOPT_POSTFIELDS, http_build_query($fields)); |
| var request = require('request'); | |
| // app below needs to be a Connect/Express app. | |
| // Subscribing: use https://push.superfeedr.com/ to use Superfeedr (works with any feed!) | |
| function subscribe(url, conf, cb) { | |
| var hub = conf.hub; | |
| var params = { | |
| method: 'POST', | |
| uri: hub, |
| var foo = { | |
| key1: "a", | |
| key2: "b", | |
| key3: "c" | |
| }; | |
| // node, modern browsers | |
| Object.keys(foo).forEach(function (key, i, keys) { | |
| console.log(key, foo[key]); | |
| }); |
Since password managers are big and complicated and I currently am pretty bored since I am sitting in a car for a few hours, here is a simple algorithm to generate resource-specific, unique passwords using a master password and no password database.
As pointed out here: http://news.ycombinator.com/item?id=4374888 this method is broken.
| #!/usr/bin/env sh | |
| ## | |
| # This is script with usefull tips taken from: | |
| # https://github.com/mathiasbynens/dotfiles/blob/master/.osx | |
| # | |
| # install it: | |
| # curl -sL https://raw.github.com/gist/2108403/hack.sh | sh | |
| # |
| require 'gollum/frontend/app' | |
| require 'digest/sha1' | |
| class App < Precious::App | |
| User = Struct.new(:name, :email, :password_hash, :can_write) | |
| before { authenticate! } | |
| before /^\/(edit|create|delete|livepreview|revert)/ do authorize_write! ; end | |
| helpers do |
| # This is Neocities' Rainbows! config file. We are using this in production to run all our web apps. | |
| # It works really well for us and has been heavily load tested, so I wanted to share it with the community. | |
| # | |
| # In my opinion, this is the best way to deploy a ruby web application. Unlike EventMachine based solutions, | |
| # it uses real ruby threads, which allows it to take advantage of the internal non-blocking IO pattern | |
| # in MRI. | |
| # | |
| # Contrary to popular belief, MRI doesn't block execution to wait on IO when you are using threads, even | |
| # with the GIL. The requests are done concurrently for anything that is based on the IO class. This | |
| # includes things like Net::HTTP and even `system commands`. Grep the MRI Ruby source code for |
| // | |
| // UIDeviceHardware.h | |
| // | |
| // Used to determine EXACT version of device software is running on. | |
| #import <Foundation/Foundation.h> | |
| @interface UIDeviceHardware : NSObject | |
| - (NSString *) platform; |
| ## install mapnik 2.x (trunk) from nightlies | |
| # be careful with this because these change nightly | |
| # and may require you re-compile apps using mapnik | |
| # after you run `apt-get upgrade` post installation of mapnik | |
| apt-get install python-software-properties | |
| apt-add-repository ppa:mapnik/nightly-trunk | |
| sudo apt-get update | |
| sudo apt-get install libmapnik2 libmapnik2-dev mapnik2-utils python-mapnik2 | |
| ## install ruby |
