| #!/bin/zsh | |
| # standalone script to build qBittorent for macOS (including Apple Silicon based Macs) | |
| # | |
| # only Xcode must be installed (Xcode 12 is required to produce arm64 binaries) | |
| # all required dependencies and tools are automatically downloaded and used only from script's working directory | |
| # (can be specified), nothing is installed into the system | |
| # working directory is removed on completion if it was not specified | |
| # | |
| # by default script produces binaries for the architecture it was launched on, but cross-compilation is also supported | |
| # in both directions, i.e. x86_64 -> arm64 and arm64 -> x86_64 |
~/wireguard/.lswg () {
ls ~/wireguard/ | cut -d '-' -f 2 | sed 's/\.conf//'
}lswg | xargs -I {} ping -c 10 {}-wireguard.mullvad.net | tee mullvadwgstats
Unfortunately as of writing this (Oct 18, 2017) there is no built in integration for multiple target groups per AWS ECS service. Here are a few things you can try:
| // Install the latest Xcode, with the Command Line Tools. | |
| // Install Homebrew | |
| // Install aircrack-ng: | |
| brew install aircrack-ng | |
| // Create the following symlink: | |
| sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/sbin/airport | |
| // Figure out which channel you need to sniff: | |
| sudo airport -s |
| #!/bin/bash | |
| # Outputs a pipeline that targets agents that have the same 'name' meta-data | |
| # value as the step that does the pipeline upload. This means that all the | |
| # steps will run on the same agent machine, assuming that the 'name' meta-data | |
| # value is unique to each agent. | |
| # | |
| # Each agent needs to be configured with meta-data like so: | |
| # | |
| # meta-data="name=<unique-name>" |
| # Get IAM Role name from Instance Profile Id | |
| curl http://169.254.169.254/latest/meta-data/iam/info | |
| # Get credentials | |
| curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> | |
| # More info | |
| http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html | |
| #/etc/puppet/environments/production/manifests/java01.pp | |
| node 'java01.example.lan' inherits default { | |
| file { '/etc/httpd/ssl': | |
| ensure => 'directory', | |
| owner => 'root', | |
| group => 'root', | |
| mode => '0640', | |
| recurse => 'remote', | |
| source => 'puppet:///files/ssl/example.com', | |
| } |
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j