RalfZ's blog (English)

Starting from a Problem on Euler's Totient Function

2019-01-14T15:47:47.000Z

Today someone in a group chat shared Problem 69 from Project Euler, saying their algorithm ran for 40 minutes before it found the answer. That made me curious about what kind of problem it was. Here it is:

Euler’s Totient function, φ(n) [sometimes called the phi function], is used to determine the number of numbers less than n which are relatively prime to n. For example, as 1, 2, 4, 5, 7, and 8, are all less than nine and relatively prime to nine, φ(9)=6.

n	Relatively Prime	φ(n)	n/φ(n)
2	1	1	2
3	1,2	2	1.5
4	1,3	2	2
5	1,2,3,4	4	1.25
6	1,5	2	3
7	1,2,3,4,5,6	6	1.1666…
8	1,3,5,7	4	2
9	1,2,4,5,7,8	6	1.5
10	1,3,7,9	4	2.5

It can be seen that n=6 produces a maximum n/φ(n) for n ≤ 10.
Find the value of n ≤ 1,000,000 for which n/φ(n) is a maximum.

The problem itself is easy to understand. But a pure brute-force solution would probably take those 40 minutes, so we need something more elegant.

After reading the problem, my intuition said the answer should be the product of the primes taken from the smallest up (2 * 3 * 5…), stopping at the largest product below the 1,000,000 limit.

So I came up with this:

function isPrime(n) {
 for (let i = 2; i * i <= n; i++) {
 if (n % i === 0) return false;
 }
 return n >= 2;
}

const LIMIT = 1000000;
let n = 1;
for (let p = 2; n * p <= LIMIT; p++) {
 if (isPrime(p)) n *= p;
}
console.log(n); // 510510

from math import isqrt

def is_prime(n):
 return n >= 2 and all(n % i for i in range(2, isqrt(n) + 1))

LIMIT = 1_000_000
n, p = 1, 2
while n * p <= LIMIT:
 if is_prime(p):
 n *= p
 p += 1
print(n) # 510510

The answer is 510510. I submitted it, and it was correct!
It is simply the product of the primes from 2 to 17, also known as the primorial of 17 (written 17#).

Now let’s go back and look at the reasoning behind it.

The problem asks for the maximum of n/φ(n).
So we want φ(n) to be as small as possible while n is as large as possible.
That means n should share a common factor with as many of the numbers below it as possible.
So we might as well build n by multiplying primes smaller than it, from the smallest up (a common factor of 2 covers far more numbers than 7 does). That covers the most numbers without wasting any of n’s size (multiplying by 2 a second time doesn’t help at all).

OK, the intuition turns out to be right. So how do we prove it mathematically?

The Wikipedia article on Euler’s totient function has everything we need.
Following the derivation there, we have:

\varphi(n) = \prod_{i=1}^{r} p_i^{k_i-1}(p_i-1) = \prod_{p \mid n} p^{\alpha_p-1}(p-1) = n \prod_{p \mid n} \left(1-\frac{1}{p}\right)

So what the problem ultimately asks us to maximize is:

\frac{n}{\varphi(n)} = \frac{1}{\prod_{p \mid n} \left(1-\frac{1}{p}\right)}

To make the right-hand side as large as possible, we make the denominator as small as possible.
Every factor in the denominator’s product is less than 1, so we want as many primes p as possible, and the smaller the better.
Hence n should be built by multiplying primes, starting from the smallest one (2).

So the answer is 2 * 3 * 5 * 7 * 11 * 13 * 17 = 510510.

Getting Started with Travis CI

2018-01-25T06:34:00.000Z

The Problem

Once we finish a feature, we usually need to build the project and publish it to a server. The “simplest” way is to build it locally and send it to the server by hand, with scp or similar. But that is tedious, since we have to go through the whole process manually every time. So we want a way to automate it.

The Solution

Here we use Travis CI for continuous integration. It works with GitHub and provides an online command runner that reads the .travis.yml config file in the project and runs the commands configured in it.
Taking this project as an example, we watch the project’s master branch. Once development on the dev branch is done, we merge the changes into master. Travis then detects the change on master and runs the build command yarn run build. When the build is done, it runs scp -r dist name@8.8.8.8:/direction to deploy the dist folder to the server.
Besides the Travis config file, there is one more problem to solve: unless it is trusted, Travis has to enter a password every time it runs scp. The fix is simple. We send the public key of our local dev machine to the server, so the server trusts the dev machine. Then we give the dev machine’s private key to Travis, so Travis can pose as the dev machine and run scp without a password. (More: public-key cryptography)
But that raises another problem. If we upload the private key to GitHub, the key becomes public, and the server gets hacked in no time. So we encrypt the private key file with Travis’s encrypt-file, and Travis decrypts it when it runs. That keeps the key safe.

Steps

Create a .travis.yml file on the master branch of the GitHub project.
Sign in to https://travis-ci.org/ with your GitHub account and enable the project you want to set up.

Generate a key pair on the local dev machine
ssh-keygen -t rsa

Copy the public key to the server (create the file on the server if it doesn’t exist)
cat .ssh/id_rsa.pub | ssh user@8.8.8.8 "cat >> ~/.ssh/authorized_keys"

The server now trusts the local dev machine. Try logging in with ssh: it won’t ask for a password.

The next step is to encrypt the private key.

First, install Ruby. Some pitfalls:

Version 2.5.0 currently pulls in dependencies that are too new, so installing Travis fails. Version 2.4.* is recommended. (This post was published in January 2018.)
Because of the notoriously bad network in mainland China, installing locally may fail. I recommend sending the private key to the server and encrypting it there with Travis.

Install Travis
gem install travis

In the project directory, encrypt the private key
travis encrypt-file ~/.ssh/id_rsa --add

You’ll find that .travis.yml now contains the following

1
2
3

before_install:
- openssl aes-256-cbc -K $encrypted_04c64bd82511_key -iv $encrypted_04c64bd82511_iv
 -in ~/.ssh/id_rsa.enc -out ~/.ssh/id_rsa -d

If you encrypted the key on the server, now copy the encrypted private key file id_rsa.enc into your local repository, and delete the unencrypted private key to stay safe.

Copy the decryption command above into your local .travis.yml, changing ~/.ssh/id_rsa.enc to ./id_rsa.enc.

That solves the main encryption problem. Next, two improvements:

Restrict the permissions of the id_rsa file, so that ssh will use the key file
Add the server to Travis’s list of trusted hosts

The config file now reads:

before_install:
- openssl aes-256-cbc -K $encrypted_04c64bd82511_key -iv $encrypted_04c64bd82511_iv
 -in id_rsa.enc -out ~/.ssh/id_rsa -d
- chmod 600 ~/.ssh/id_rsa
- echo -e "Host 8.8.8.8\n\tStrictHostKeyChecking no\n" >> ~/.ssh/config

Finally, complete the rest of .travis.yml.
The config file is simple, so I won’t explain it further here.

language: node_js
node_js:
- node
- '8'
before_install:
- openssl aes-256-cbc -K $encrypted_04c64bd82511_key -iv $encrypted_04c64bd82511_iv
 -in id_rsa.enc -out ~/.ssh/id_rsa -d
- chmod 600 ~/.ssh/id_rsa
- echo -e "Host 8.8.8.8\n\tStrictHostKeyChecking no\n" >> ~/.ssh/config
install:
- yarn install
script:
- yarn run build
after_success:
- scp -r dist name@8.8.8.8:/direction

References

https://docs.travis-ci.com/
https://cnodejs.org/topic/5885f19c171f3bc843f6017e (in Chinese)
http://www.voidcn.com/article/p-aglpzloh-c.html (in Chinese)

Ngrok Setup Guide: Exposing a Local Machine to the Internet

2017-12-27T16:59:51.000Z

The Problem

Lately I’ve been developing some APIs on my home computer. Locally, I can reach them at http://localhost:8000. But once I leave home, there is no way to reach them directly over the internet.
If I committed and deployed to my VPS every time before going out, there would be two problems:

It’s a real hassle.
Sometimes the code is still being developed and debugged, and isn’t ready to be deployed to the VPS.

The best solution is to use a public domain and port as a relay that leads straight to a port on the dev machine at home. That is, I can visit http://xxx.ralfz.com:8081 to get the content of http://localhost:8000.
Below, we’ll use ngrok to solve this problem.

What You Need

A VPS on the public internet
A domain name pointing to that VPS
A dev machine, like my home computer

On the Server

My VPS runs CentOS. Here are the steps.

Install the tools:

1	sudo yum install build-essential golang mercurial git

Make sure they all install successfully.
(For me, build-essential failed to install. Following this answer on StackExchange, I solved it with sudo yum groupinstall 'Development Tools'.)

Download ngrok:

1 2	git clone https://github.com/inconshreveable/ngrok.git ngrok cd ngrok

Generate the certificates (replace the domain with your own VPS’s domain):

NGROK_DOMAIN="yourdomain.com"
openssl genrsa -out base.key 2048
openssl req -new -x509 -nodes -key base.key -days 10000 -subj "/CN=$NGROK_DOMAIN" -out base.pem
openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=$NGROK_DOMAIN" -out server.csr
openssl x509 -req -in server.csr -CA base.pem -CAkey base.key -CAcreateserial -days 10000 -out server.crt

cp base.pem assets/client/tls/ngrokroot.crt

Build ngrokd, the server:
sudo make release-server

Start it:
sudo ./bin/ngrokd -tlsKey=server.key -tlsCrt=server.crt -domain="yourdomain.com" -httpAddr=":8081" -httpsAddr=":8082"

Once it’s running, you’ll see:

Visiting yourdomain.com:8081 shows Tunnel yourdomain.com:8081 not found, which means the server has started successfully.

Next, we need to build the ngrok client for the client’s platform. My client (the dev machine) runs 64-bit Windows, so I run this on the VPS:

1	GOOS=windows GOARCH=amd64 make release-client

The settings for each platform:

Linux, 32-bit: GOOS=linux GOARCH=386
Linux, 64-bit: GOOS=linux GOARCH=amd64
Windows, 32-bit: GOOS=windows GOARCH=386
Windows, 64-bit: GOOS=windows GOARCH=amd64
Mac, 32-bit: GOOS=darwin GOARCH=386
Mac, 64-bit: GOOS=darwin GOARCH=amd64
ARM: GOOS=linux GOARCH=arm

Build the ngrok client for your own client platform.
After a successful build, the client files are generated under ./bin, in a folder named after the client platform (mine is ./bin/windows_amd64).

Finally, copy the client folder to the client computer with scp or similar, for the next step.

(Note: keep the server running.)

On the Client

Open the client folder you copied over, and you’ll see the ngrok executable. In that folder, add a new file ngrok.cfg with the following content:

1 2	server_addr: yourdomain:4443 trust_host_root_certs: false

Finally, start it with the following command:

1	ngrok.exe -subdomain=pub -proto=http -config=ngrok.cfg 8000

Here, 8000 is the local port on the client that you want to reach from the internet, and pub is the subdomain.

Now open pub.yourdomain.com:8081, and you’ll see your local service.

Wrapping Up

Those are the basic steps for exposing a local machine with ngrok. The tool can do a lot more, which I’ll explore over time.