5-minute smart contract on ETH-compat blockchain network ?
.. Yes, it is very possible .. if you already have some knowledge about it.
5-min ETH Smart Contract
Tag Archives: linux
ftp.th.debian.org
Well, ftp.th.debian.org was NXDOMAIN for 2+ years.
Not anymore:
Yes, I’m running ftp.th.debian.org. :)
CVE-2019-14287 – sudo
Thre is a bug in sudo before 1.8.28. The bug, basically, involve UID validation where user ID -1 or 4294967295 could allow a user with sudo privilege to run command as root, even the Runas specification explicitly disallow root access.
For example, specify Runas in /etc/sudoers like this:
test ALL=(ALL,!root) /usr/bin/whoami
You can do this:
Fix ? Just update the package.
Upgrading Graylog from 2.2 to 2.3
Well, my installation is based on the official deb package. However, you cannot automatically upgrade from 2.2 to 2.3. I think this is because graylog might change things overtime and they don’t want to break things without administrator’s supervision.
So you need to download and dpkg -i to install it manually.
You should also check upgrading to 2.3.x docs where they describe changes that may impact your configuration.
For my case, I decide to upgrade and replace my existing graylog.conf with the maintainer’s configuration. Then, copy password hashes from the existing one to the new one.
It runs smoothly though.
Deja-Dup / Duplicity / GPG
Some Linux users user Deja-Dup / Duplicity to backup their files. The tools work pretty well and very reliable.
However, in very rare occasions, Deja-Dup will keep asking you a password even you put the right one. To debug this, you can do
DEJA_DUP_DEBUG=1 deja-dup --backup
to see what’s going on, and grabbing those error messages to find the right solution.
Interestingly, one of those occasions is that you have files with size = 0 byte in your backup set. These zero-byte files cause GPG fails when it tries to test your backup set even with the right password.
To solve this, simple, delete those zero-byte files from the backup set. It is safe to do so anyway. :P
1,500,000,000 seconds after the Unix Epoch
Unix epoch to date
$ date --date @<number of seconds>
Date to Unix epoch
$ date +%s
Google Cloud Platform Free Tier
Google recently provide the free tier on their Google Cloud Platform (GCP). The free tier will be free forever (but what Google offered are subjected to changes).
Also included in the free tier is $300 credit for 12 months (I think this was 2 months – good !)
I applied, created Google Compute Engine (GCE) f1-micro instance, ran the same benchmarks as I did on Vultr, DO, and Scaleway.
The best results I got from the instance:
dd write bs=4k count=10k 100k 1M
1500 39.6 37.5 MB/s
dd read bs=4k 63.1 MB/s
sysbench --test=cpu --cpu-max-prime=10000 run 11.7567 sec.
stress-ng --cpu 1 --cpu-method all -t 30 156.75 ops/sec
BUT …
The results were not consistent. I ran the dd write 5 more times, the results varied from 211 MB/s to 1.5 GB/s. sysbench results varied from 11 to 13 sec. stress-ng varied between 50 – 150 ops/sec.
I think this is because almost all the resources for free tier (CPU, disk, network) are shared among others.
It’s free, though.
Vultr’s $2.5 / month server instance
Vultr has recently upgrade all instances . While $5/month has been upgraded from 1 CPU / 768 MB / 15 GB to 1 CPU / 1 GB / 25 GB, Vultr also introduced the new smallest server instance – 1 CPU / 512 MB / 20 GB at $2.5/month.
So, I have choices: keep paying $5/month and get an upgraded instance for free, or migrate to the $2.5/month to cut cost in half.
I chose the latter.
Unfortunately, Vultr does not allow to downgrade the instance (because disks can only be enlarged). So, I needed to migrate the server. I created a snapshot from the existing 15 GB disk, and deployed an $2.5/month instance from the snapshot. It took me about 10 minutes to create the snapshot (free), and few more minutes to deploy new instance. Then, I updated DNS record.
Things went well. So, finally, I destroyed the $5/month instance.
The result ? You are seeing it right now. This web is running on single $2.5/month instance :D
CPU overloaded by kidle_inject ?
As it’s named, kidle_inject is a process to inject idleness to processors.
On a good day, this will keep idle your processors, lower processor temperature, and save your battery.
On a bad day, it will consume your processor somewhat like 50%+ on all cores, slow down your laptop, and drain your battery.
But, you can control this. Many new Intel-based processors could use intel_pstate driver to manage processor power consumption. If you use intel_pstate, you can drop intel_powerclamp (which would run kidle_inject). help your laptop to consume less power.
Just
# modprobe -r intel_powerclamp
Or, consider to put
blacklist intel_powerclamp
in your /etc/modules (or modprobe)
YMMV.
Intel® Optimized LINPACK Benchmark on Debian and Ubuntu
Got a chance to grab 8 dedicated servers. All of them are identical configuration.
- Intel Xeon E5-2660 2.20 GHz – 8 Core / 16 Threads
- 16GB (DDR3) Memory
- 240GB (SSD) Storage
- 1 Gbps Network Port
And I put Debian on 2 of them and Ubuntu 2 of them. Since I use these servers for computation, I tested all of them by running Intel LINPACK Benchmark.
The results:
Ubuntu 16.04.2 / Linux 4.4.0
Size LDA Align. Average Maximal 1000 1000 4 57.1781 63.1674 2000 2000 4 96.3596 99.1686 5000 5008 4 120.8776 121.0789 10000 10000 4 129.6896 129.7670 15000 15000 4 132.1119 132.1371 18000 18008 4 133.5032 133.6047 20000 20016 4 134.7515 134.7724 22000 22008 4 134.7769 134.8034 25000 25000 4 135.2187 135.2249 26000 26000 4 135.3471 135.3511 27000 27000 4 135.7265 135.7265 30000 30000 1 135.9339 135.9339 35000 35000 1 136.3998 136.3998 40000 40000 1 136.0928 136.0928 45000 45000 1 135.4024 135.4024
Ubuntu 16.10 / Linux 4.8.0
Size LDA Align. Average Maximal 1000 1000 4 67.6860 75.8030 2000 2000 4 97.1338 98.9928 5000 5008 4 120.8437 120.9400 10000 10000 4 129.5845 129.5925 15000 15000 4 132.0033 132.0423 18000 18008 4 133.5847 133.5954 20000 20016 4 134.7129 134.7186 22000 22008 4 134.7988 134.8389 25000 25000 4 135.1581 135.1615 26000 26000 4 135.2965 135.2966 27000 27000 4 135.7175 135.7175 30000 30000 1 135.8775 135.8775 35000 35000 1 136.3674 136.3674 40000 40000 1 136.0681 136.0681 45000 45000 1 135.6452 135.6452
Debian 8.7 / Linux 3.16.0
Size LDA Align. Average Maximal 1000 1000 4 57.1597 62.6083 2000 2000 4 87.6385 96.1681 5000 5008 4 115.0042 115.2121 10000 10000 4 120.6037 120.7413 15000 15000 4 126.8568 126.8810 18000 18008 4 128.2295 128.2299 20000 20016 4 128.9295 128.9335 22000 22008 4 129.7550 129.7679 25000 25000 4 130.2622 130.2687 26000 26000 4 130.4710 130.4769 27000 27000 4 130.1460 130.1460 30000 30000 1 131.0764 131.0764 35000 35000 1 131.8341 131.8341 40000 40000 1 131.7159 131.7159 45000 45000 1 131.6021 131.6021
Debian 8.7 / Linux 4.8.0
Size LDA Align. Average Maximal 1000 1000 4 73.9033 75.2857 2000 2000 4 96.1756 98.1587 5000 5008 4 114.9453 115.1133 10000 10000 4 120.6623 120.6715 15000 15000 4 126.8516 126.8579 18000 18008 4 128.1927 128.1953 20000 20016 4 128.9059 128.9097 22000 22008 4 129.7727 129.8013 25000 25000 4 130.2268 130.2318 26000 26000 4 130.4389 130.4403 27000 27000 4 130.1010 130.1010 30000 30000 1 131.1211 131.1211 35000 35000 1 131.8388 131.8388 40000 40000 1 131.7462 131.7462 45000 45000 1 131.6341 131.6341
Now, can anyone tell me why Debian is slower ? .. hmm