Command Flags
Flag | Options | Description |
---|---|---|
-codec:a |
libfaac, libfdk_aac, libvorbis | Audio Codec |
-quality |
best, good, realtime | Video Quality |
-b:a |
128k, 192k, 256k, 320k | Audio Bitrate |
-codec:v |
mpeg4, libx264, libvpx-vp9 | Video Codec |
Let's Encrypt Certificates are awesome. It is a great way to upgrade your websites to use https or SSL. If you’re using a fairly common/basic setup it’s fairly straightforward to configure your server to use Let’s Encrypt certificates.
Recently, I was working on a project. Where, it was required to use wildcard certificate. Meaning dynamically created domains like abc.example.com
or xyz.example.com
can be made to use https without needing to manually create a new certificate for each subdomain. Though, the setup was pretty common (Route53, Nginx, CentOS7), I wasn't able to find clear documentation of configuring wildcard certificated for mentioned stack.
To archive our goal, we will need Certbot, Python Pip, Certbot Plugin for Route53 and an AWS user with access to Route53 to generate Let's Encrypt Certificate.
I assum
1. Using lua_resty_auto_ssl
.
Internally, lua-resty-auto-ssl uses dehydrated as it's Let's Encrypt client. If you'd like to adjust lower-level settings, like the private key size, public key algorithm, or your registration e-mail, these settings can be configured in a custom dehydrated configuration file.
- For a full list of supported options, see dehydrated's example config.
- Custom dehydrated configuration files can be placed inside the
/etc/resty-auto-ssl/letsencrypt/conf.d
directory by default (or adjust the path if you've changed the default lua-resty-auto-ssldir
setting).
There are a number of ways to install the AWS command line tools. Below is the method I favour on CentOS:
$curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
$unzip awscli-bundle.zip
$cd awscli-bundle/
$sudo ./install -i /usr/local/aws -b /usr/local/bin/aws
Check that was successful with:
CGO không hỗ trợ trực tiếp tính năng về class trong C++. Nguyên nhân đến từ việc CGO không có hỗ trợ cho cú pháp C++, ngoài ra C++ cũng không có sẵn một Application Binary Interface (ABI) nào cả.
Nhưng do C++ tương thích với C, do đó chúng ta có thể thêm một tập các hàm C cho interface như là cầu nối giữa C++ class và CGO. Dĩ nhiên, bởi vì CGO chỉ hỗ trợ kiểu dữ liệu của ngôn ngữ C, chúng ta không thể trực tiếp dùng C++ reference parameters và các tính năng khác.
Việc hiện thực packaging C++ class thành Object trong Go yêu cầu một số bước:
CGO là cầu nối giữa Go và C, cho phép khả năng tương tác ở cấp độ nhị phân, nhưng chúng ta nên chú ý đến các vấn đề có thể phát sinh do sự khác biệt về mô hình bộ nhớ giữa hai ngôn ngữ.
Trong phần này chúng ta sẽ cùng làm rõ vấn đề đó.
Vùng nhớ của không gian ngôn ngữ C khá ổn định, miễn là nó không bị release trước, thì không gian ngôn ngữ Go có thể truy cập được. Truy cập vùng nhớ C trong Go là trường hợp đơn giản và chúng ta đã thấy nó nhiều lần trong các ví dụ trước.