A recreation of this Dribbble shot: https://dribbble.com/shots/16755073-Almeria-Neobank-Dashboard/attachments/11802960?mode=media
A Pen by Håvard Brynjulfsen on CodePen.
A recreation of this Dribbble shot: https://dribbble.com/shots/16755073-Almeria-Neobank-Dashboard/attachments/11802960?mode=media
A Pen by Håvard Brynjulfsen on CodePen.
str=part1/part2/part3 | |
# part1 | |
echo ${str%%/*} | |
# part1/part2 | |
echo ${str%/*} | |
# part2 | |
echo ${${str%/*}#*/} | |
# part2/part3 | |
echo ${str#*/} | |
# part3 |
There is an increasing count of applications which use Authy for two-factor authentication. However many users who aren't using Authy, have their own authenticator setup up already and do not wish to use two applications for generating passwords.
Since I use 1Password for all of my password storing/generating needs, I was looking for a solution to use Authy passwords on that. I couldn't find any completely working solutions, however I stumbled upon a gist by Brian Hartvigsen. His post had a neat code with it to generate QR codes for you to use on your favorite authenticator.
His method is to extract the secret keys using Authy's Google Chrome app via Developer Tools. If this was not possible, I guess people would be reverse engineering the Android app or something like that. But when I tried that code, nothing appeared on the screen. My guess is that Brian used the
Hosting multiple websites on a single public IP address on the standard HTTP(S) ports is relatively easy with popular web servers like Apache, Nginx and lighttpd all supporting Virtual Hosts.
For Web Services which bundle their own HTTP server, things get more complicated, unless their HTTP stack can be shared somehow. More often than not, the application's HTTP stack listens directly on a dedicated TCP port.
Hosting multiple services on a single IP then requires using a fronting server listening on the standard HTTP port, and routing to the right backend service based on the host name or the path sent by the client.
Path based routing is cumbersome, usually requiring either the service to be aware of the path prefix, or a rewrite by the HTTP fronting server of all absolute URLs in the requests and responses.
Hostname based routing is more straightforward. The fronting server can just look at the [HTTP/1.1 Host header](https://tools
Today I wanted to move existing APFS-resident macOS Catalina installation to a new disk. I upgraded my late 2014 Mac Mini with a shiny new 1TB SSD. This took way too many hours of my life I will never get back. Hope this saves some time to you.
Good news:
This information is relevant for Catalina (I'm currently running macOS 10.15.1).
package main | |
import ( | |
"fmt" | |
"log" | |
"strconv" | |
"github.com/miekg/dns" | |
) |
router id [our IPv4]; | |
protocol bgp vultr | |
{ | |
local as [our ASN]; | |
source address [our IPv4 from vultr]; | |
import all; | |
export filter { | |
if net ~ [[the IPv4 block we want to announce]] then accept; | |
reject; |
package main | |
import ( | |
"log" | |
"bufio" | |
"time" | |
"os" | |
"fmt" | |
"io" | |
"net" |
#!/bin/sh | |
# To be used with something like this in sshd_config: | |
# | |
# Match User public-tmux | |
# X11Forwarding no | |
# AllowTcpForwarding no | |
# PasswordAuthentication yes | |
# ForceCommand /usr/bin/tmux -S /tmp/public-tmux-socket attach -r -t public | |
# |
# Key considerations for algorithm "RSA" ≥ 2048-bit
openssl genrsa -out server.key 2048
# Key considerations for algorithm "ECDSA" ≥ secp384r1
# List ECDSA the supported curves (openssl ecparam -list_curves)