Git and gnutls_handshake() failed: Error in the pull function errror

Tag

,

Tidak dapat melakukan pull atau clone ke github.com, mengakibatkan beberapa fungsi tidak dapat berjalan di server.

Saat dilakukan test ke github.com:

userptsp@Investor:~$ curl -vvv https://github.com
* Trying 20.205.243.166:443...
* Connected to github.com (20.205.243.166) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to github.com:443
* Closing connection 0
* TLSv1.0 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, decode error (562):
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to github.com:443

Selain itu saat dilakukan test menggunakan openssl tidak didapatkan hasil.

userptsp@Investor:~$ openssl s_client -connect github.com:443
CONNECTED(00000003)
^C

Sampai ditunggu beberapa lama, tampilan tidak terlihat dan terpaksa harus mengklik tombol CTRL^C untuk menghentikan proses. Melakukan proses upgrade git, sampai instalasi libssl-dev, masih tidak dapat berjalan. Hingga saat mendapatkan beberapa komentar dari sumber yang menyatakan untuk menurunkan nilai mtu pada network interface yang dipakai.

root@Investor:~# ip link list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0@if84: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff link-netnsid 0
root@Investor:~# ip link set dev eth0 mtu 1400

Sebelumnya nilai mtu menggunakan nilai 1500, diturunkan ke 1400, dan permasalahan terselesaikan.

Sumber:

Mempercepat Proses Install (download) Paket Aplikasi Menggunakan Snap

Saat melakukan proses download sebagai bagian instalasi menggunakan snap, selalu mendapatkan kecepatan yang begitu lambat. Hal ini sangat tidak nyaman karena kita harus menunggu proses download terlebih dahulu dengan kecepatan yang mengecewakan.

Download snap "vlc" (2344) from channel "stable"          6% 9.26kB/s 8h42

Seperti salah satu capture proses download vlc pada salah satu komputer, membutuhkan waktu hingga 8 jam lebih.

Dari salah satu tips yang didapatkan dari https://ubuntuhandbook.org/index.php/2019/11/speep-up-downloading-snap-app/, hal ini disebabkan karena untuk melakukan download snap mendapatkan aplikasi terpilih melalui CDN yang disediakan oleh provider fastly, di mana proses download terkadang dilakukan menggunakan bandwidth internasional.

Untuk mempercepatnya proses maka kita akan melakukan setting agar sistem snap langsung melakukan download melalui sebuah alamat yang kita set secara static pada nilai DNS local kita ( /etc/hosts).

$ dig fastly.cdn.snapcraft.io

; <<>> DiG 9.16.1-Ubuntu <<>> fastly.cdn.snapcraft.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29980
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;fastly.cdn.snapcraft.io.	IN	A

;; ANSWER SECTION:
fastly.cdn.snapcraft.io. 300	IN	A	36.86.63.182

;; Query time: 444 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sel Feb 22 21:13:58 WIB 2022
;; MSG SIZE  rcvd: 68

Perhatikan nilai IP dari fastly.cdn.snapcraft.io yang didapatkan dari hasil query DNS di atas, pada mesin saya mendapatkan nilai 36.86.63.182. Kemudian tambahkan ini pada bagian akhir isian /etc/hosts

# mempercepat snapcraft waktu install snap
36.86.63.182 fastly.cdn.snapcraft.io

Setelah melakukan ini, proses download di komputer saya lumayan cepat.

Download snap "vlc" (2344) from channel "stable"          77% 207kB/s 5m2s

Menggunakan Lubuntu Pada Laptop Tua

Laptop yang saya gunakan sudah tua, ditandai dengan sistem yang semakin melambat dan akhirnya mencapai level tidak dapat digunakan lagi dengan nyaman. Kemudian akhirnya pada minggu kemarin telah mencapai level sudah tidak bisa lagi digunakan.

Merknya adalah Toshiba Qosmio F750, sudah sangat tua dan telah menemani saya selama lebih dari 8 tahunan. Dari test yang dilakukan, selain hardisk sudah mencapai masa purnatugas akibat sepanjang tahun telah disiksa dengan pemakaian gila, speaker adalah komponen yang sudah tidak bisa hidup lagi. Sedangkan komponen utama laptop ini, yaitu memory masih dalam kondisi baik berdasarkan test, keyboardnya pun masih seempuk dulu sejak pertama kali saya gunakan; ini adalah keistimewaan yang membuat saya susah beralih kepada yang lain. Walaupun diakui suara kipas yang terkadang hidup terus saat sedang dinyalakan menunjukkan sesuatu yang tidak normal.

Singkat cerita, pilihan pun diambil untuk melakukan upgrade, karena membeli laptop baru belum bisa dilakukan akibat ketiadaan budget.

Pada pilihan upgrade ini, mengganti speaker dianggap hal yang tidak mungkin. Walaupun tentu saja masih bisa menggunakan speaker external, saya sendiri lebih menyukai mendengarkan musik dari app spotify di-handphone dibandingkan menjalankannya di laptop. Setelah itu untuk mengganti hardisk yang sudah rusak, saya memilih Visipro SSD 256 GB. Alasannya selain saya tidak butuh space besar, ini SSD yang paling terjangkau budget saya.

Berikutnya adalah pilihan OS dan sayapun memilih versi “hemat daya Ubuntu” yaitu Lubuntu. Pilihan ini karena kondisi hardware di laptop, kemudian OS sebelumnya saya menjalankan fulltime Ubuntu yang berat, sehingga dari pengalaman Lubuntu adalah pilihan bijak. Di lain pihak saya sendiri lebih banyak menggunakan laptop ini untuk development beberapa project pemrograman web ( siapa yang mau kerjasama? 😀 ) berbasis OctoberCMS dan aplikasi custom lainnya, tidak membutuhkan konfigurasi desktop yang keren layaknya Gnome di Ubuntu.

Dari hasil setelah seminggu lebih, ringannya Lubuntu dan ngebutnya SSD mengakibatkan saya seperti mendapatkan komputer baru lagi. Sangat direkomendasikan untuk digunakan, walaupun seperti biasa: fungsi office-nya sangat terbatas karena LibreOffice yang saya gunakan agak bermasalah pada render font-nya. Hal ini mengakibatkan saya lebih menyukai untuk menggunakan Google Doc pada setiap pekerjaan pelaporan. Selain itu, saya benar-benar menyukai sistem yang tua tapi baru ini.

Melakukan Cek Terhadap IMAP SSL Port Menggunakan Telnet

Tag

Salah satu aplikasi membutuhkan proses pembacaan terhadap inbox lalu dilanjutkan dengan memindahkan email terbaca tersebut ke folder lainnya, sehingga membutuhkan akses email menggunakan IMAP.

Namun dari user interface aplikasi, tidak dapat melakukan login ke IMAP server.

Dilakukanlah proses melakukan pengecekan:

$ openssl s_client -connect mx.server.ku:993
4146403072:error:0200206F:system library:connect:Connection refused:../crypto/bi                                                                                                             o/b_sock2.c:110:
4146403072:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b                                                                                                             _sock2.c:111:
connect:errno=111

Mencurigai pesan connection refused tersebut, maka percobaan login dilakukan dari luar server dan proses tersebut bisa dilakukan dengan baik. Hal ini menunjukkan terdapat setting pada firewall server yang tidak benar untuk port 993. Maka langkah selanjutnya adalah membuka firewall pada server sehingga port 993 bisa lewat dari mesin keluar, kemudian dilanjutkan dengan pengecekan konek kembali.

$ openssl s_client -connect mx.server.ku:993
CONNECTED(00000004)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
<<isi content lain>>
read R BLOCK
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) ready.

Muncul kemudian notifikasi tersebut di atas, sehingga bisa dilanjutkan dengan percobaan login menggunakan userid yang sudah ada pada server.

a login "user-id@server.ku" "password-rahasia"
a OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDS                                                            UBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH E                                                            SORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY LITERAL+ NOTIFY SPECIAL-USE QUOTA ACL RI                                                            GHTS=texk] Logged in
e logout
* BYE Logging out
e OK Logout completed (0.001 + 0.000 secs).
closed

Berarti memang permasalahan ada pada firewall.

.httaccess RewriteRule Pada URL yang Keliru

Salah satu client memiliki web OJS dengan link:

https://jurnal.keren.org/ejurnal/index.php/journalmedic/view/article/134

Jadi pada suatu waktu yang lalu, di mana semua orang sedang sibuk karena sesuatu dan lain hal, pada waktu ada pembagian link yang digunakan oleh beberapa pengguna web tersebut untuk menampilkan hasil penelitian mereka, alih-alih menggunakan link yang benar sebagaimana contoh mereka menggunakan link berikut:

https://jurnal.keren.org/ejurnal/index.php/journalmedis/view/article/134

Perhatikan pada penulisan journalmedis yang semestinya journalmedic.

Pada kasus ini apabila pengunjung mengakses URL yang keliru, maka yang terjadi adalah sistem OJS akan menampilkan form login, karena jurnal dengan nama journalmedis tidak ada. Salah satu solusi dipilih daripada harus melakukan penambahan koding pada index.php dan tidak benar melakukan perubahan langsung pada file package, maka opsi menggunakan fasilitas RewriteRule-pun dipilih.

Untuk itu perlu dilakukan perubahan pada URL yang keliru, sehingga sistem me-redirect ke URL yang benar. OPsi untuk menggunakan RewriteRule pada .htaccess diimplementasikan karena provider hosting kami yang dermawan telah mengaktifkan opsi untuk menggunakan RewriteRule ini.

Berikut .httaccess yang digunakan untuk kasus ini:

RewriteEngine On
RewriteBase /ejurnal
RewriteCond %{REQUEST_URI} /ejurnal/index.php/journalmedis(.*) [NC]
RewriteRule (.*)index.php/journalmedis(.*) /ejurnal/index.php/journalmedic%1 [R,NC,L]

Pada baris RewriteBase /ejurnal digunakan karena tempat utama load aplikasi ini adalah bukan pada bagian root dari web, melainkan pada folder /ejurnal.

Baris RewriteCond %{REQUEST_URI} /ejurnal/index.php/journalmedis(.*) melakukan pemeriksaan kondisi apakah nilai variable REQUEST_URI memiliki nilai journalmedis? Bila ia maka lanjutkan ke baris perintah berikutnya, di mana opsi NC menyatakan bahwa mode perbandingan karakter adalah tidak case sensitive (karakter a sama dengan A).

Baris RewriteRule (.)index.php/journalmedis(.) /ejurnal/index.php/journalmedic%1 [R,NC,L] kemudian melakukan perintah untuk melakukan penulisan ulang dan opsi R melakukan redirect ke alamat yang benar, sedangkan L menyatakan ini adalah baris terakhir yang harus dieksekusi.

Referensi dan tools:

Bagaimana Cara Mengetahui Apakah Kita Berada Di screen Session?

Tag

Pada banyak pekerjaan sebagai system admin atau yang menyerempet hal itu, di mana kita harus banyak berhubungan dengan penggunaan screen, saya saking lamanya berada di sebuah screen session sering lupa, apakah saya ada didalam thread utama atau masuk didalam screen session.

Karena hampir tidak terlihat perbedaan yang signifikan bila menggunakan ssh remote ke salah satu server.

Hingga didapatkan informasi bahwa saat berada di dalam sebuah screen session ada variable env yaitu $TERM dan $STY yang bisa memberikan kita informasi tentang itu. Di bawah ini adalah saat dijalankan diluar screen session.

$> echo $STY

$> echo $TERM
xterm-256color

Sedangkan berikut ini adalah isi varible tersebut disaat dijalankan pada sebuah screen session.


$> echo $STY
2521.pts-0.DESKTOP-CI6HM25
$> echo $TERM
screen.xterm-256color

Salah satu lagi cara lain adalah, dengan menekan tombol CTRL-A dan dilanjutkan menekan tombol titik dua “:” sebagaimana salah satu tips untuk memberika nama sebuah screen session, bila muncul tempat mengetikkan perintah maka berarti sedang berada di sebuah screen session.

Sumber:

Create Extract File tar.gz

Tag

Ini adalah salah satu perintah yang sering terlupakan, ketika berhadapan dengan kebutuhan untuk melakukan pembuatan file arsip dengan utility tar dan kompresi format gz.

Misalnya ada file dari salah satu server backup bernama etc.tar.gz yang berisikan file-file hasil backup dari folder /etc di server production. Ingin di-extract hasilnya, maka menggunakan perintah:

$ tar -xzvf etc.tar.gz -C /etc

Pada perintah tersebut bahwa opsi yang digunakan adalah:

  • x opsi untuk eXtract
  • z opsi bahwa file menggunakan algoritma kompresi gZ
  • v opsi untuk menampilkan proses
  • f opsi untuk menunjukkan file
  • C opsi untuk menunjukkan lokasi kita melakukan extract

Kemudian untuk melakukan kompresi, sebagai kebalikannya adalah:

$ tar -czvf etc.tar.gz /etc

Pada perintah tersebut:

  • c opsi untuk melakukan pembuatan arsip file tar

Selain menggunakan opsi kompresi gz, kita bisa juga menggunakan zip yang menghasilkan file relatif kecil (kompresi lebih bagus) namun dengan kecepatan proses lebih lama dibandingkan yang lain.

$ tar -cJvf backup-semua-sql.sql.tar.zip *.sql

Perintah di atas akan membuat file tar dengan kompresi menggunakan zip.

Untuk opsi lain yang sangat banyak bisa dilihat manual dengan melakukan perintah man tar.

Instalasi Lets’ Encrypt SSL pada Apache reverse proxy Menggunakan acmesh

Tag

,

Ada permasalahan saat menggunakan acme.sh pada sebuah aplikasi yang dijalankan menggunakan reverse proxy di Apache, yaitu disaat Let’s Encrypt melakukan proses verifikasi dengan mengakses http://web.site.kita.com/.well-known/acme-challenge/hashid-challenge-lets-encrypt, akan selalu terjadi kegagalan karena acme.sh melakukan generate content challenge tersebut (check doc di: https://letsencrypt.org/docs/challenge-types/) bukan pada tempat yang dikenali oleh apache.

Sebelumnya, pada aplikasi yang berjalan menggunakan reverse proxy di Apache paling tidak berisikan virtualhost seperti berikut:

<VirtualHost *:80>
        ServerName web.site.kita.com
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>
<VirtualHost *:443>
        SSLEngine on
        SSLCertificateFile    /root/ssl/ca.pem
        SSLCertificateKeyFile   /root/ssl/web.site.kita.com.pem

        ServerName web.site.kita.com
        ServerAdmin webmaster@web.site.kita.com

        ProxyPass / http://localhost:3000/ nocanon
        ProxyPassReverse / http://localhost:3000/
        LogLevel info ssl:warn

        ErrorLog /home/log/website/web.site.kita.com/error.log
        CustomLog /home/log/website/web.site.kita.com/access.log combined

</VirtualHost>

Pada setting virtualhost di atas, semua koneksi akan dilarikan ke jaringan HTTPS tanpa terkecuali. Untuk itu, supaya proses verifikasi Let’s Encrypt bisa dijalankan dengan baik kita harus menyediakan mekanisme rewrite url pada koneksi HTTP, di mana koneksi tidak akan di-redirect ke HTTPS apabila merupakan proses verikasi Let’s Encrypt; atau koneksi tersebut mengakses url /.well-known/acme-challenge/. Sebagai asumsi bahwa SSL certificate yang digunakan di atas berada di /root/ssl/ca.pem dan /root/ssl/web.site.kita.com.pem dan ini akan kita lakukan perubahan.

Untuk itu kita lakukan penambahan perintah untuk melakukan exclude pada RewriteCond, serta di sini kita akan menempatkan file hasil generate dari mekanisme challenge di folder /var/www/html. Hasilnya adalah seperti ini:

<VirtualHost *:80>
        ServerName web.site.kita.com
        RewriteEngine On
        # jangan di redirect ke https bila let's encrypt challenge
        RewriteCond %{REQUEST_URI} !^/\.well\-known/
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
        # hanya untuk set lets encrypt menggunakan reverseproxy
        DocumentRoot /var/www/html
        <Directory /var/www/html>
            Order allow,deny
            Allow from all
            AllowOverride All
            Require all granted
        </Directory>
</VirtualHost>

Setelah melakukan perubahan ini agar dilakukan test untuk mengakses ke url web.site.kita.com/.well-known dengan membuat sebuah file testing. Misalnya:

# echo "test 123" > /var/www/html/.well-known/test123.txt
# apache2ctl configtest
# service apache2 reload

Apabila setting di atas berjalan ( jangan lupa melakukan reload pada service apache2 ), maka dilakukan ujicoba akses ke url web.site.kita.com/.well-known/test123.txt. Apabila berhasil, bisa dilanjutkan dengan langkah berikutnya.

Agar memudahkan pemeliharaan, SSL certificate hasil generate menggunakan tools acme.sh akan disimpan di folder /etc/apache2/acmesh-ssl/, sehingga dilakukan pembuatan folder-nya.

# mkdir /etc/apache2/acmesh-ssl/

Langkah berikutnya adalah melakukan setting terhadap lokasi SSL certificate-nya pada virtualhost.

<VirtualHost *:443>
        SSLEngine on

        ServerName web.site.kita.com
        ServerAdmin webmaster@web.site.kita.com

        ProxyPass / http://localhost:3000/ nocanon
        ProxyPassReverse / http://localhost:3000/
        LogLevel info ssl:warn

        SSLCipherSuite HIGH:!aNULL:!MD5
        SSLCertificateFile /etc/apache2/acmesh-ssl/web.site.kita.com-cert.pem
        SSLCertificateKeyFile /etc/apache2/acmesh-ssl/web.site.kita.com-key.pem
        SSLCertificateChainFile "/etc/apache2/acmesh-ssl/letsencrypt.pem"

        ErrorLog /home/log/website/web.site.kita.com/error.log
        CustomLog /home/log/website/web.site.kita.com/access.log combined

</VirtualHost>

Setelah semua proses tersebut di atas, jangan lupa melakukan generate SSL menggunakan tool acme.sh dan instalasi ke /etc/apache2/acmesh-ssl sebagaimana yang terdokumentasikan.

# apache2ctl configtest
# service apache2 reload
# acme.sh --issue -d web.site.kita.com -w /var/www/html/
# acme.sh --install-cert -d web.site.kita.com \
> --cert-file /etc/apache2/acmesh-ssl/web.site.kita.com-cert.pem \
> --key-file /etc/apache2/acmesh-ssl/web.site.kita.com-key.pem \
> --fullchain-file /etc/apache2/acmesh-ssl/letsencrypt.pem \
> --reloadcmd "service apache2 reload"

Kemudian dilanjutkan dengan testing menggunakan tool online atau langsung diujicoba melakukan akses ke url utama.

Notes: terkadang membutuhkan restart pada service apache2.

Referensi:

Let’s Encrypt Menggunakan acme.sh Pada Shared Hosting

Tag

,

Setelah berhasil menggunakan acme.sh pada beberapa kasus di sini dan di situ, terdapat lagi masalah pada salah satu shared hosting yang mengalami kendala dikarenakan satu dan lain hal, tidak bisa melakukan generate untuk sertifikat SSL-nya menggunakan Let’s Encrypt. Untunglah pada shared hosting tersebut menyediakan akses untuk menggunakan SSH, dan instalasi acme.sh tidak membutuhkan akses sebagai root.

Langkah dilakukan untuk melakukan instalasi acme.sh sebagaimana tulisan tersebut di atas, lalu dilakukan perintah …

$ acme.sh --issue -d domain.punya.kami.com -w ~/path/web/ke-domain/nya/web --debug

Saya jalankan debug supaya bisa dilihat kalau ada permasalahan, secara ini adalah shared hosting.

Hasilnya berhasil dan didapatkan hasil generate-nya, biasanya ada di ~/.acme.sh/domain.punya.kami.com/

Langkah selanjutnya adalah melakukan aktivasi sertifikat SSL yang dimiliki, dalam hal ini yang dimintakan ada 3 file: private key (ada di domain.punya.kami.com.key), TLS (ada di domain.punya.kami.com.cer) serta CA (ca.cer).