Multi-Page Blueprints for Confluence
A free demo app is available in the Atlassian Marketplace which supports multi-page blueprints for Confluence. This app works around numerous bugs in the official Atlassian blueprint tutorials and a key Atlassian API bug.
Background on Confluence
Confluence is one of the leading enterprise wiki products. Its built-in feature set is already very powerful, and it can be extended with applications available in the Atlassian Marketplace. You can also write your own applications for private, internal use. Atlassian provides the atlassian-connect-express toolkit for building apps with Node.js, which reduces development time and effort. They also provide a number of sample projects for Jira and Confluence apps on Bitbucket. Unfortunately, many of these examples are obsolete or deprecated, and do not function correctly with the latest version of atlassian-connect-express or the latest release of Confluence and Jira.
Node.js: Connecting to MySQL on a socket with Sequelize
According to its official description, “Sequelize is a promise-based Node.js ORM for Postgres, MySQL, MariaDB, SQLite and Microsoft SQL Server.” Sequelize is widely used in Node.js web applications to abstract the database layer. I recently found a “corner case” for Sequelize which is possible to accomplish, but is not well documented anywhere on the web. I need to use Sequelize to connect to a MySQL server via a UNIX socket. I’m developing some plugins for Confluence that use the atlassian-connect-express toolkit, which has a datastore that wraps Sequelize. The way Atlassian has chosen to wrap Sequelize is rather unfortunate, probably because they are trying to maintain backwards compatibility with JugglingDB. Essentially, the Atlassian Connect Express only looks at the URL, and ignores any option passed to Sequelize. Therefore, you have to pass everything you need via the URL, and this is where it’s tricky. Here’s the form of the URL that you need to connect to MySQL via a UNIX socket with Sequelize:
Alert Policies for Log Metrics on Google Stackdriver Monitoring
Google Cloud Operations, formerly known as Stackdriver Logging and Monitoring, can be very confusing to set up. It’s easy to monitor something simple, but more complex cases quickly get confusing. One of the more flexible but confusing types of alert policies in Stackdriver Monitoring is a Logs-Based Metrics policy, which gives you the ability to monitor entries in Stackdriver Logging.
Create a Logs-Based Metric
The first step is to go to Stackdriver (Operations) Logging and create a user-defined metric. Go to the Logs Viewer and build a query to return the subset of log entries that you want to monitor (the details of query building are beyond the scope of this article). As of Sept. 2020, I highly recommend enabling the Preview Mode of the Logs Viewer interface, which is much better at guiding you through the process of building the query. If you must use the Classic interface, click the little black arrow at the right side of the filter box, near the top of the Logs Viewer screen. Select “Convert to advanced filter” from the drop-down menu, and create an advanced filter using the query language. Once you have created the right filter (query) that selects the log entries that you want to monitor, proceed to the next step:
curl or libcurl: SSL certificate problem: unable to get local issuer certificate
curl, or an application that uses libcurl, may have a problem with an SSL certificate that works fine when using a web browser to access the same URL. Typical error output from curl looks like this:
$ curl -v https://my-subdomain.mysecuresite.com
Trying xxx.xxx.xxx.xxx:443…
TCP_NODELAY set
Connected to my-subdomain.mysecuresite.com (xxx.xxx.xxx.xxx) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (OUT), TLS alert, unknown CA (560):
SSL certificate problem: unable to get local issuer certificate
Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.Troubleshooting Strategy
- A good starting point for any SSL error on a public-facing URL is to analyze the URL at SSL Labs.
- Does the error happen for all certificates issued by a specific Certificate Authority (CA)? If so, the system running curl may need to have a root certificate for that CA added or updated in its certificate repository. That’s a relatively rare problem, but might occur if the system running curl is very old. There’s a comprehensive thread about this issue on Stack Overflow.
- If the error only happens for one specific site, it’s likely that the site is missing an intermediate certificate. The command to diagnose this issue is also found in that Stack Overflow thread:
openssl s_client -connect myhost.com:443 -servername myhost.com -showcertsThe output should show a series of certificates, starting with the site certificate, and ending with the root certificate for the Certification Authority. If this chain only shows the site certificate, that’s the problem.
openssl unable to read/load/import SSL private key from GoDaddy
openssl is the standard open-source, command-line tool for manipulating SSL/TLS certificates on Linux, MacOS, and other UNIX-like systems. I recently ran into an interesting problem using openssl to convert a private key obtained from GoDaddy. Someone else used GoDaddy’s “wizard” interface to generate a certificate signing request (CSR) and private key, and saved the files on their Windows workstation. They purchased an SSL cert from GoDaddy, and shared all the files with me for installation on servers. GoDaddy saved the private key in the newer PKCS #8 format (pkcs8), and one system required the key in the older PKCS #1 (pkcs1) format. It’s easy to tell the difference.
Nginx default user changed in RedHat/CentOS package nginx-1.16.1-1.el7
The latest Nginx rpm (nginx-1.16.1-1.el7) from EPEL for CentOS/Redhat is a fairly major update, from version 1.12 to 1.16, and includes some very important fixes to address multiple CVEs. There is another small but critical change in the latest RPM that isn’t mentioned in the bug report. RedHat had configured nginx to run as user “apache” in past releases, but in the EPEL release on 19 October 2019, the configuration was changed to run as user “nginx”. If you ran “yum upgrade” recently (which you really need to do on a regular basis) on any system with nginx installed, you probably have a system that is affected.
Another Reason to Enable Private IP Addresses on Google Cloud SQL
Google Cloud SQL recently introduced the capability for an instance to have an IP address within the private address space of your VPC network. Previously, all Cloud SQL instances had IP addresses within the address space of the public Internet. Obviously, the public IP was a security and privacy concern, as well as a potential violation of some compliance and governance frameworks. Now, each instance may have a public IP, private IP, or both. There’s another potential benefit to using a private IP address: performance!
Managing remote servers with salt-ssh
I love using Salt to configure and manage servers at scale. Typically, a Salt master server manages an army of servers which are on the same private network. A salt-minion daemon runs on each client server and communicates with the master. Sometimes you need to manage a server which is outside of your internal network, such as a marketing web server running on a service like AWS LightSail, Linode, or Digital Ocean. That’s when salt-ssh comes in handy.
Find Last Login Time for Wordpress Users in the SQL Database
Question: What are the timestamps for the last login for every Wordpress user in this Wordpress site?
Most answers say to install some plugin, and there are dozens that will show the date and time when each Wordpress user last logged in. However, plugins are a problem, because they always need to be kept up to date, and many plugins get abandoned. Now, you have a potential security problem. Also, this approach assumes that your Wordpress front-end is up and running; if your site has been hacked or accidentally broken, you need to go into the database to do some forensics.