3.3. Operations Deployment: Lập lịch task, kernel parameter và quản lý package

Mục lục

• 1. Ba cách lập lịch task
• 2. Cú pháp crontab và năm trường thời gian
• 3. Crontab của user và các thư mục cron có sẵn
• 4. anacron cho job theo ngày
• 5. at cho job chạy một lần
• 6. Kernel runtime parameter với sysctl
• 7. Quản lý package với apt
• 8. Repository và PPA
• 9. Cài software từ source code

---

1. Ba cách lập lịch task

Trên server, thỉnh thoảng cần dựng một task tự chạy theo lịch. Ví dụ cụ thể: backup database mỗi Chủ nhật lúc ba giờ sáng. Có ba cách chính để dựng loại task như vậy, bằng utility cron, bằng anacron, hoặc bằng utility tên at. Mỗi cái sinh ra cho một mục đích khác nhau.

cron phù hợp với job lặp lại, chạy mỗi vài phút, mỗi vài giờ, hoặc vào những ngày và giờ cụ thể.

anacron cũng dùng để tạo job lặp lại, nhưng khác vài điểm. Thứ nhất, nó không lặp job theo đơn vị vài phút hay vài giờ: đơn vị nhỏ nhất nó làm việc được là một ngày. Nên nó chạy được job mỗi ngày, hoặc mỗi ba ngày, mỗi tuần, thậm chí mỗi tháng hay mỗi năm, nhưng không chạy một job nhiều lần trong ngày, chỉ một lần mỗi ngày.

Lý do anacron ra đời: cron bỏ sót job nếu máy không bật nguồn liên tục. Một job hẹn chạy hàng ngày vào buổi trưa, mà máy lại được bật lúc 12 giờ 01, thì job đó không chạy cho ngày hôm ấy. anacron thì kiểm tra xem job của hôm nay đã có cơ hội chạy chưa; chưa thì nó thực thi, bất kể hệ thống được bật nguồn lúc nào.

at đi theo hướng ngược lại với hai cái trên. cron và anacron tập trung vào task lặp lại và tự động, còn at tập trung vào task chỉ cần chạy đúng một lần.

---

2. Cú pháp crontab và năm trường thời gian

Cú pháp một cron job khó nhớ trong vài lần đầu, nhưng có sẵn một bản nhắc trên máy:

cat /etc/crontab

Đây là system-wide crontab mặc định, và các dòng comment trong đó mô tả cú pháp cần dùng. Cần thêm một cron job vào đây thì thêm một dòng mới ở cuối file, ví dụ:

35 6 * * * root /usr/bin/touch /tmp/test-pass

Năm giá trị đầu nói cho cron biết job chạy khi nào. Giá trị thứ sáu là username, và sau nó là lệnh cần chạy. cron thực thi lệnh như thể user ghi ở trường username đã khởi chạy task đó.

Điểm cần cân nhắc khi thêm job vào system-wide crontab mặc định: trong một số trường hợp, package manager có thể ghi đè file này và các thay đổi đã thêm sẽ mất, ví dụ khi package manager nâng cấp cron. Vì vậy phần thực hành dưới đây thêm cron job bằng cách sửa crontab riêng của một user, không sửa bảng system-wide. Nhưng khi quản lý server của người khác thì nên nhớ trình tự tra cứu: tìm cron job trong bảng system-wide /etc/crontab trước, rồi tới crontab của user root.

Giờ tới năm giá trị quyết định cron job chạy lúc nào. Hai trường đầu chọn thời điểm trong ngày: minute từ 0 tới 59, và hour từ 0 tới 23. Hai trường kế tiếp chọn ngày trong tháng từ 1 tới 31, và tháng từ 1 tới 12. Trường cuối chọn ngày trong tuần từ 0 tới 6, với 0 là Chủ nhật, 1 là thứ Hai, 2 là thứ Ba và tiếp tục như vậy.

Trường cuối này hơi dễ nhầm, vì cảm giác tự nhiên là nó phải nhận số từ 1 tới 7. Nên cron cũng chấp nhận cách ghi thay thế, với 1 là thứ Hai và 7 là Chủ nhật.

Ký tự đặc biệt trong các trường thời gian

Thay vì số cố định, các trường này nhận được cả những ký tự đặc biệt.

• Dấu *, tức asterisk hay star, khớp với mọi giá trị có thể của trường đó. Một dấu * ở trường hour nghĩa là chạy vào mọi giờ, từ 0, 1, 2 cho tới 23.
• Dấu , dùng để liệt kê nhiều giá trị cho một trường. Muốn chạy ở phút 15 và phút 45 thì ghi 15,45 ở trường đầu tiên, không có khoảng trắng.
• Dấu - dùng để khai một khoảng. Muốn lập lịch một job chạy vào ban đêm, ở các giờ 2, 3 và 4 sáng, thì ghi 2-4 ở trường thứ hai.
• Dấu / khai một step. Nếu trường hour là dấu * thì cron bước qua từng giờ một, tức step mặc định là 1: job chạy lúc 0 giờ, rồi 1 giờ, rồi 2 giờ, và tiếp tục. Muốn nó chạy mỗi bốn giờ thì đổi step thành 4 bằng cách ghi */4: job chạy lúc 0 giờ, rồi 4 giờ, rồi 8 giờ, 12 giờ và tiếp tục.

Khoảng và step kết hợp được với nhau. Ví dụ cần chạy đúng ba mốc giờ là 0 giờ, 4 giờ và 8 giờ thì ghi 0-8/4 ở trường hour: 0-8 khai khoảng từ 0 giờ tới 8 giờ, còn /4 bảo cron bước qua khoảng đó theo bước bốn giờ.

---

3. Crontab của user và các thư mục cron có sẵn

Cách thực hành nhanh nhất là thêm một cron job chỉ tạo ra một file: nhìn file đó có được tạo vào đúng giờ hay không là biết job có chạy đúng hay không. Trong cron job thì chạy được cả lệnh lẫn shell script. Ví dụ dưới đây dùng lệnh touch, và việc đầu tiên cần làm là tìm đường dẫn đầy đủ tới lệnh đó:

which touch

# Output:
/usr/bin/touch

Trong cron job thì luôn phải dùng đường dẫn đầy đủ tới lệnh. Để sửa crontab của một user, dùng option -e, tức edit:

crontab -e

Lệnh này sửa crontab của chính user đang đăng nhập. Để chạy lệnh touch và tạo một file tên test-pass mỗi ngày lúc 6 giờ 35 sáng, thêm dòng:

35 6 * * * /usr/bin/touch test-pass

Ở đây không còn trường username như trong system-wide crontab. Nó không cần thiết nữa, vì lần này cron biết bảng này thuộc về user nào và nó tự biết phải chạy lệnh dưới quyền user đó. Lưu file rồi thoát text editor là xong việc thêm một cron job.

Vài cách ghi thời gian khác để tham khảo:

0 3 * * 0    /usr/bin/touch test-pass
0 3 * * 7    /usr/bin/touch test-pass
0 3 15 * *   /usr/bin/touch test-pass
0 3 * * *    /usr/bin/touch test-pass
0 * * * *    /usr/bin/touch test-pass

Hai dòng đầu đều là mỗi Chủ nhật lúc ba giờ sáng, theo hai cách ghi ngày trong tuần đã nói ở mục trên. Dòng thứ ba chạy vào giữa mỗi tháng, ngày 15 lúc ba giờ sáng. Dòng thứ tư chạy mỗi ngày lúc ba giờ sáng. Dòng cuối chạy mỗi giờ một lần, vào lúc phút bằng 00.

Muốn luyện viết cron expression cho quen thì có trang web www.crontab.guru.

Xem, sửa và xóa crontab

crontab -l
sudo crontab -l
sudo crontab -e

Option -l, tức list, xem crontab của user hiện tại. Thêm sudo phía trước là xem crontab của user root, và tương tự với -e nếu muốn sửa bảng của root.

Để sửa crontab của một user khác thì có hai cách. Một là đăng nhập làm user đó rồi dùng các lệnh crontab thông thường. Hai là dùng option -u, tức user:

sudo crontab -u jane -e

Chỉ root sửa được crontab của user khác, nên lệnh này buộc phải có sudo. Để xóa hẳn crontab của user hiện tại thì dùng option -R chữ hoa, tức remove, và để xóa crontab của một user khác thì kết hợp với -u:

crontab -r
sudo crontab -r -u jane

Các thư mục cron có sẵn

Có một cách khác để dựng cron job, qua các thư mục đặc biệt sau: /etc/cron.daily, /etc/cron.hourly, /etc/cron.monthly và /etc/cron.weekly. Bất cứ thứ gì cron tìm thấy trong các thư mục này, nó chạy theo đúng nhịp daily, hourly, monthly hay weekly tương ứng.

Hình dung có một shell script trong thư mục local, tên gọn là shell-script. File script này không được có extension nếu muốn dùng nó làm cron job theo cách này: đừng đặt tên kiểu shell-script.sh khi có ý định dùng nó với cron. Tình huống ít gặp mà phần viết script của Part 3.1: Boot, systemd service và bash script có nhắc tới chính là trường hợp này.

Để nó chạy mỗi giờ, trình tự là:

sudo cp shell-script /etc/cron.hourly/
sudo chmod +rx /etc/cron.hourly/shell-script

Bước đầu copy script vào /etc/cron.hourly, cần quyền root vì chỉ user root ghi được vào thư mục này. Bước sau đảm bảo script có quyền đọc và quyền thực thi, để cron chạy được nó. Về sau cần bỏ cron job này thì chỉ việc xóa file đi.

---

4. anacron cho job theo ngày

Trên một số hệ thống Ubuntu, anacron có thể chưa được cài sẵn:

sudo apt install anacron

Khi dùng anacron thì không quan tâm job chạy vào giờ nào. Điều cần là nó chạy daily, monthly, hoặc mỗi vài ngày một lần, bất kể là giờ nào trong ngày. Để lập lịch một job với anacron, sửa file /etc/anacrontab:

sudo vim /etc/anacrontab

Trong file này có vài gợi ý sẵn. Thứ nhất là nó chỉ tới manual của anacrontab ở section 5, nơi có chi tiết về cú pháp:

man 5 anacrontab

Thứ hai là ở cuối file đã có ba entry anacron sẵn làm ví dụ sống. Cú pháp khá đơn giản, một dòng anacrontab có bốn trường:

3	10	test.job	/usr/local/bin/myscript

Dòng này làm job chạy một lần mỗi ba ngày, với delay mười phút, job identifier (tức tên của job) là test.job, rồi tới lệnh. Lệnh trong job này chạy dưới quyền user root. Muốn nó chạy mỗi tuần hoặc mỗi tháng thì đổi trường chu kỳ ở đầu dòng cho khớp.

Sau khi lưu file, nên xác minh cú pháp đã viết có đúng hay không bằng option -T, tức test:

anacron -T

Có lỗi thì lệnh in ra thông báo; cú pháp đúng thì nó không in gì cả.

---

5. at cho job chạy một lần

Trên hệ thống Ubuntu, at cũng có thể chưa được cài sẵn:

sudo apt install at

Lập lịch bằng at dễ hơn nhiều: chỉ cần khai thời điểm muốn job chạy. Ví dụ muốn một việc chạy vào 15 giờ:

at 15:00

Rồi gõ các lệnh muốn chạy vào thời điểm đó, ví dụ:

/usr/bin/touch file-created-by-at

Ở đây cũng dùng đường dẫn đầy đủ tới lệnh, dù với at thì đó không phải yêu cầu bắt buộc: gõ touch không kèm tiền tố /usr/bin vẫn được. Sau mỗi lệnh thì nhấn Enter. Cần thêm lệnh thứ hai, thứ ba thì gõ tiếp. Sau khi nhấn Enter ở lệnh cuối cùng, tại dòng trống kế tiếp thì nhấn Ctrl-D để lưu job này lại.

Job cũng lập lịch được vào một ngày cụ thể, hoặc vào một ngày cụ thể kèm một giờ cụ thể. Và at nhận cả thời gian tương đối:

at now + 30 minutes
at now + 3 hours

Dòng đầu chạy job 30 phút sau, dòng sau chạy 3 giờ sau. Tương tự với ngày, tuần và tháng. Phần khai ngày giờ phải được bọc trong cặp nháy đơn.

Xem và xóa at job

atq

# Output (minh họa):
1	Fri Oct 24 15:00:00 2026 a jeremy

Số đầu tiên trong output là job ID, dùng cho các lệnh phía sau. Về sau có thể quên một job đó đáng lẽ làm gì, nên có option -c, tức cat, giống lệnh cat in nội dung một file, để in ra nội dung của một at job:

at -c 1

Output của lệnh này khá dài, nhưng các lệnh đã thêm vào at job nằm ở những dòng cuối. Để xóa một at job đã lập lịch, đưa job identifier của nó vào cuối lệnh atrm:

atrm 1

Service quản lý daemon at là atd.service. Nếu service đó inactive thì at job đã lập lịch sẽ không được thực thi, cách soát nằm ở Part 3.2: Process, log hệ thống và giám sát tài nguyên.

---

6. Kernel runtime parameter với sysctl

Kernel runtime parameter là cách gọi hoa mỹ cho những thiết lập về cách kernel Linux làm việc nội bộ. Vì kernel lo các thứ ở tầng thấp như cấp phát bộ nhớ hay xử lý network traffic, phần lớn thiết lập này cũng quay quanh những việc đó.

Để xem toàn bộ kernel runtime parameter đang dùng:

sysctl -a

Không phải parameter nào cũng đọc được: thỉnh thoảng sẽ thấy các dòng báo permission denied. Muốn chắc chắn mọi parameter đều hiện ra thì chạy lại lệnh đó với quyền root:

sudo sysctl -a

Quy ước đặt tên làm việc đoán ý nghĩa một parameter khá dễ. Mọi thứ bắt đầu bằng net. là parameter liên quan tới mạng. Thứ liên quan tới bộ nhớ bắt đầu bằng vm., tức virtual memory. Thiết lập về file system trong kernel Linux bắt đầu bằng fs..

Ví dụ với net.ipv6.conf.all.disable_ipv6, một parameter dạng bật tắt, giá trị của nó là 0. Với loại parameter này, 0 nghĩa là false và 1 nghĩa là true. Tên parameter mô tả hành vi tắt IPv6, nên 0 nghĩa là không tắt, tức IPv6 vẫn đang hoạt động, và muốn tắt IPv6 thì đặt thành 1. Đọc tên parameter trước khi đoán chiều giá trị là cách duy nhất không bị lẫn, vì có parameter thì 1 là bật tính năng, có parameter thì 1 lại là tắt một tính năng khác.

Bài giảng gốc nêu đúng quy ước 0 là false và 1 là true, nhưng ngay sau đó lại nói muốn tắt thì đặt về 0. Hai câu ngược nhau, và câu đúng là đặt thành 1.

Để ghi giá trị cho một parameter thì dùng option -w, tức write. Không được có khoảng trắng trước hay sau dấu =:

sudo sysctl -w <tên-parameter>=<giá-trị>

Nhưng đây là thay đổi không bền vững. Nó có hiệu lực từ lúc này nếu hệ điều hành tiếp tục chạy, nhưng reboot một cái là thiết lập quay về giá trị mặc định của nó. Thay đổi kiểu này không sống qua được lần reboot.

Để đọc giá trị hiện tại của một parameter thì gõ sysctl kèm đúng tên parameter đó; nếu giá trị không đọc được thì thêm sudo để có quyền root:

sysctl vm.swappiness

# Output:
vm.swappiness = 60

Làm cho thay đổi bền vững

Cách làm là thêm một file vào thư mục /etc/sysctl.d, và file đó phải có extension .conf. Chi tiết này dễ quên, nên có hai cách nhắc lại:

man sysctl.d
ls /etc/sysctl.d

Manual nói ngay rằng extension .conf là bắt buộc. Chạy ls trên thư mục đó cũng thấy sẵn vài file .conf, vừa nhắc về extension cần có, vừa làm nguồn tham khảo về cách dùng các file này; xem nội dung chúng là biết chúng được viết thế nào.

Giờ lấy một ví dụ thật. Để chỉ xem các parameter liên quan bộ nhớ, tức những cái bắt đầu bằng vm., dùng sysctl -a rồi lọc bằng grep:

sysctl -a | grep vm

# Output (rút gọn):
vm.swappiness = 60

Parameter vm.swappiness hay được người dùng cấu hình lại khi muốn đổi cách Linux hành xử lúc nó bắt đầu hết bộ nhớ trống. Có một kỹ thuật gọi là swapping, chuyển dữ liệu từ bộ nhớ sang thiết bị lưu trữ như SSD, giải phóng tạm một phần bộ nhớ cho chương trình khác dùng. Giá trị swappiness nhận từ 0 tới 100 trên các kernel cũ, và từ 0 tới 200 trên kernel mới hơn. Giá trị cao nghĩa là bảo kernel Linux rằng cứ swap khi nào muốn, kể cả khi mới có dấu hiệu nhỏ nhất là sắp thiếu bộ nhớ. Giá trị thấp nghĩa là bảo nó tránh swap bằng mọi giá, chỉ swap khi thật cần thiết.

Giả sử cần đổi giá trị này thành 20 và muốn thay đổi bền vững, tức reboot vẫn giữ nguyên. Trước hết tạo một file .conf trong /etc/sysctl.d. Tên file đặt tùy ý, ví dụ swap-less để báo cho người quản trị khác biết file này được tạo ra để hệ thống swap ít hơn:

sudo vim /etc/sysctl.d/swap-less.conf

Nội dung file chỉ một dòng:

vm.swappiness=20

Lưu file lại. Từ nay mỗi lần hệ điều hành Linux boot, parameter này được đặt thành 20: nó đã bền vững. Nhưng có một chỗ mắc: cho tới lần boot kế tiếp, swappiness vẫn đang dùng giá trị cũ là 60. Muốn Linux áp ngay các parameter theo đúng cách đã định nghĩa trong file thì chạy thêm:

sudo sysctl -p

Man page của sysctl không nói rõ vì sao option này tên là -p, nhưng có thể nhớ nó như việc đọc thiết lập từ một permanent file.

Còn một chỗ nữa sửa được kernel parameter là file /etc/sysctl.conf:

sudo vim /etc/sysctl.conf

Điểm hay của file này là nó có kèm giải thích về các parameter quan trọng và hay bị đổi, nên nó cho thêm chút ngữ cảnh về tác dụng của một số parameter trước khi thực sự đổi chúng. Nó cũng đặt sẵn những parameter đó trong file, dễ bật lên bằng cách bỏ comment ở dòng tương ứng. Nhưng file đó có thể bị ghi đè khi nâng cấp hệ điều hành, nên các thay đổi bền vững của mình vẫn nên đặt vào thư mục /etc/sysctl.d.

---

7. Quản lý package với apt

Linux làm việc cài, xóa và nâng cấp software trở nên dễ nhờ một package management system. Trên Ubuntu, lệnh dùng để quản lý software là apt, viết tắt của Advanced Package Tool.

Trước khi cài hay nâng cấp bất cứ thứ gì, chạy:

sudo apt update

Lệnh này làm mới database local của các package có sẵn. Thông tin đó được tải về từ các repository, tức những server lưu thông tin về package và lưu cả bản thân các package. Package management system duy trì một database về những package mà nó biết tới, và thông tin đó cũ dần đi: chạy apt update lần cuối từ một tuần trước thì chỉ có thông tin về các package có sẵn vào một tuần trước. Lệnh này làm mới thông tin đó trên máy bằng cách tải phần cập nhật từ repository. Các repository của Ubuntu do Canonical duy trì.

Tới lúc nâng cấp thì:

sudo apt upgrade

Gõ Y rồi Enter để xác nhận. Hai lệnh này nối được vào nhau cho gọn:

sudo apt update && sudo apt upgrade

Chúng chạy theo đúng thứ tự đó: update xong việc mà không lỗi thì apt upgrade mới vào chạy tiếp. Nhờ vậy package manager chắc chắn đã biết về software mới nhất trên repository trước khi nó cố nâng cấp bất cứ thứ gì.

Cài một package

sudo apt install nginx
sudo apt update && sudo apt install nginx

Dòng thứ hai lại nối hai lệnh, đảm bảo lấy được phiên bản mới nhất và chặn việc package manager cài một phiên bản cũ. Trong output sẽ thấy việc cài NGINX cũng cài theo một số dependency, tức các package mà software cần có để chạy đúng, ví dụ library hoặc các phần mở rộng tính năng.

Vậy một package là gì? Nó là một archive chứa các file mà một phần mềm cần tới, có thể gồm binary, file cấu hình, tài liệu và nhiều thứ khác, tất cả đóng gói chung lại cho dễ cài.

Sau khi cài một package, xem các file trong package bằng tool dpkg:

dpkg --listfiles nginx
dpkg --listfiles nginx-core

# Output (rút gọn):
/usr/sbin/nginx

Ở đây thấy chương trình nginx thật nằm ở /usr/sbin/nginx. Việc này làm được theo chiều ngược lại. Để biết binary /usr/sbin/nginx thuộc package nào:

dpkg --search /usr/sbin/nginx

# Output:
nginx-core: /usr/sbin/nginx

Nó được kéo vào bởi package nginx-core. Còn các dependency khác mà NGINX kéo theo, ví dụ libnginx-mod-stream, thì tra bằng một lệnh khác. Để biết mục đích của một package nào đó:

apt show libnginx-mod-stream

Lệnh này in ra phần description, cho biết package gồm những gì và nó làm gì.

Tìm package

Có trường hợp không biết package nào chứa software cần dùng, nên phải tìm. Để tra mọi package có nhắc tới chữ NGINX:

apt search nginx

Cách này có thể ra rất nhiều kết quả, vì nó tìm chữ nginx trong cả tên package lẫn description của chúng. Lúc đó nên loại description ra và chỉ tìm theo tên package:

apt search --names-only nginx

Cũng tìm được package khớp nhiều từ khóa cùng lúc:

apt search nginx module image

Hàm tìm kiếm phải khớp tất cả các từ này. Lệnh như trên định vị được package NGINX chứa module cần để xử lý ảnh.

Xóa package

sudo apt remove nginx
sudo apt autoremove

Dòng đầu chỉ xóa package NGINX chính, các dependency thỉnh thoảng vẫn còn nằm lại, thường không phải điều mong muốn. Dòng sau dọn mọi thứ sót lại và các dependency không còn cần tới nữa. Thay vì hai lệnh riêng, có cách gộp trong một lệnh:

sudo apt autoremove nginx

Lệnh này xóa package NGINX cùng toàn bộ dependency của nó.

---

8. Repository và PPA

Phần lớn trường hợp, software cần dùng đã có trong các repository chính thức của Ubuntu. Các repository mặc định của hệ thống khai trong một file. Ở các phiên bản Ubuntu trước thì file đó là /etc/apt/sources.list, nhưng trên Ubuntu 24.04 thì trong file cũ có một dòng comment trỏ sang tên file mới là /etc/apt/sources.list.d/ubuntu.sources.

Đọc file mới đó theo từng dòng.

Types khai loại repository đang được định nghĩa. Giá trị deb cho biết đây là repository kiểu Debian, tức định dạng package mà Ubuntu dùng. Dòng này nói với package manager, ví dụ APT, rằng hãy trông đợi package Debian trong repository này. Các file .deb chính là các package: archive chứa những file như file chương trình, file cấu hình, tài liệu, script cần chạy và nhiều thứ nữa.

URIs khai Uniform Resource Identifier của repository. Ở đây là một URL HTTPS trỏ tới Ubuntu archive mirror đặt tại Hoa Kỳ, nhận ra qua us.archive.ubuntu.com. Đường dẫn /ubuntu ở cuối URL cho biết repository này chứa package Ubuntu. Dòng này nói với package manager rằng tải package từ đâu.

Suites khai các suite, hay release component, của repository. Trên Ubuntu, một suite là một tập package gắn với một release hoặc một phiên bản cụ thể của distribution. Phiên bản ở ví dụ này có codename là Noble, và có ba suite được khai:

• noble là suite chính của bản Ubuntu release có codename Noble Numbat, chứa các package cốt lõi của release đó.
• noble-updates chứa các bản cập nhật cho package trong suite noble, thường là bản vá lỗi, bản vá bảo mật, hoặc cải tiến tính năng nhỏ.
• noble-backports chứa các package backport từ những bản Ubuntu release mới hơn, tức package được build lại từ release mới để chạy được trên release cũ. Nhờ đó truy cập được software mới hơn mà không phải nâng cấp cả hệ thống.

Components khai các component của repository. Trên Ubuntu, component là các nhóm package được gom lại theo giấy phép, theo chức năng hoặc theo tiêu chí khác. Có bốn component được khai:

• main chứa các package là free and open-source software và được Ubuntu hỗ trợ chính thức.
• restricted chứa các package là free and open-source software, nhưng có thể có một số giới hạn về cách sử dụng hoặc cách phân phối lại.
• universe chứa các package là free and open-source software, nhưng không được Ubuntu hỗ trợ chính thức.
• multiverse chứa các package không phải free and open-source software, và có thể có các giới hạn giấy phép khác.

Trên một server thì thường chỉ cần main và universe, và tốt nhất là chỉ main nếu đủ dùng. Cần thứ gì ngoài main thì mới bật universe lên, nếu nó chưa được bật. Theo mặc định thì cả bốn component đều đang có.

Thêm repository của bên thứ ba

Có trường hợp software cần dùng không nằm trong repository chính thức của Ubuntu. Có trường hợp khác là nó có trong phần Universe của Ubuntu nhưng lại là một phiên bản rất cũ, trong khi thứ cần là bản mới nhất. Cả hai trường hợp đều giải quyết bằng cách bật third-party repository: những repository không do Ubuntu duy trì mà do một nhóm hoặc một công ty khác duy trì, nhưng vẫn tương thích với hệ điều hành này.

Ví dụ cụ thể: cần bản stable mới nhất của Docker. Việc đầu tiên là tải public key về. Khi nhóm Docker upload một package mới, họ ký nó bằng private key của họ; với public key, package manager trên máy xác minh được chữ ký đó, nhờ vậy chắc chắn package chưa bị kẻ xấu chỉnh sửa. Dùng curl với option -o để lưu thành file tên docker.key:

curl <URL-tới-public-key-của-Docker> -o docker.key

Tiếp theo dùng lệnh gpg để chuyển key này từ dạng text sang dạng binary mà package manager hiểu được. Hành động này gọi là dearmoring theo thuật ngữ GPG:

gpg --dearmor docker.key

Key đã dearmor nằm trong file docker.key.gpg: GPG lưu nội dung đã dearmor vào một file cùng tên với file gốc, chỉ thêm extension .gpg ở cuối. Giờ chuyển nó vào một thư mục thuộc package manager APT, chính là /etc/apt/keyrings, nơi APT giữ các public key của bên thứ ba để xác minh chữ ký package:

sudo mv docker.key.gpg /etc/apt/keyrings/

Cuối cùng là thêm repository Docker vào cấu hình của APT. Thay vì thêm repository mới vào file ubuntu.sources đã xem ở trên, nên tạo một file cấu hình mới trong thư mục sources.list.d. Như vậy mọi thứ được tách riêng và gọn gàng: ubuntu.sources giữ các entry mặc định, còn thư mục sources.list.d chứa một file cho mỗi repository mới thêm vào hệ thống. Khi không cần third-party repository nữa thì chỉ việc xóa file cấu hình đó khỏi thư mục. Các cách cũ dồn hết vào một file duy nhất, khiến file phình to và khó đọc, nên cách này ngăn nắp hơn.

Tạo file docker.list trong thư mục đó và thêm dòng cấu hình:

sudo vim /etc/apt/sources.list.d/docker.list

deb [signed-by=/etc/apt/keyrings/docker.key.gpg] <địa-chỉ-repository> <codename> stable

Dòng này theo định dạng khác với file ubuntu.sources, nó theo quy ước cũ của file sources list: keyword deb, rồi địa chỉ repository, rồi codename của distribution, rồi các component muốn lấy từ repository đó. Ở đây component dùng là stable để truy cập các phiên bản stable của software Docker. Còn một phần nữa bắt buộc phải có: đường dẫn tới public key dùng để xác minh chữ ký các package tải từ Docker, và nó được chèn vào ngay sau keyword deb. Hướng dẫn cho toàn bộ các bước này thường có sẵn trên trang web cung cấp third-party repository đó.

Lưu file rồi cập nhật lại database của package manager:

sudo apt update

Nhờ vậy APT tải thông tin mới từ repository Docker và cập nhật được các package mới nhất có ở đó. Để xác nhận mọi thứ đã chạy đúng, tìm trong output một dòng nhắc tới địa chỉ của repository vừa thêm. Thấy repository Docker trong output đó là xong. Nếu gặp lỗi nói rằng chữ ký không xác minh được thì public key đã dearmor chưa được cấu hình đúng.

PPA

Một loại repository khác mà Ubuntu cho phép thêm là PPA, viết tắt của Personal Package Archive. PPA đơn giản hóa toàn bộ quá trình thêm một third-party repository, và cũng cho phép tự tạo third-party repository riêng.

Hình dung một người tạo PPA với username là john, rồi đặt tên repository là mylatestapp. Sau khi upload package lên đó, người khác thêm PPA này vào bằng lệnh add-apt-repository. Tham số kế tiếp bắt đầu bằng ppa: để báo cho utility biết đây là một personal package archive, rồi tới username john, rồi tới repository mylatestapp. Với một PPA thật:

sudo add-apt-repository ppa:graphics-drivers/ppa

Ở đây tên repository đúng là ppa, vì đặt tên như vậy là thực hành khá chuẩn mực. Nhấn Enter để xác nhận hành động. Lệnh này lo hết mọi chi tiết còn lại: sửa file ubuntu.sources, thêm public key dùng để xác minh chữ ký package, cập nhật database của package manager.

Để liệt kê các PPA đang bật, truyền option --list. Để xóa một PPA, truyền option --remove kèm đúng chuỗi PPA đã dùng trước đó rồi nhấn Enter để xác nhận:

add-apt-repository --list
sudo add-apt-repository --remove ppa:graphics-drivers/ppa

---

9. Cài software từ source code

Vẫn còn một cách thứ ba để cài software. Để có phiên bản mới nhất tuyệt đối của một ứng dụng, có lúc buộc phải tải code từ một nơi như GitHub rồi tự compile. Việc đó chuyển code từ dạng người đọc được sang dạng code thực thi được mà máy tính chạy hiệu quả.

Trước tiên cần git. Nó thường đã được cài sẵn trên phần lớn phiên bản Ubuntu và Linux:

sudo apt install git

Phần dùng git nằm ở Part 2.5: SSL/TLS certificate và quản lý source code với Git. Ví dụ ở đây tải repository của một ứng dụng tên htop:

git clone <URL-repository-htop-trên-GitHub>
cd htop
ls

Trong thư mục project có một file README. Mỗi project có yêu cầu compile khác nhau, cần library khác nhau, lệnh chạy khác nhau, nên muốn biết phải làm gì để build được thì đọc hướng dẫn trong file này.

Theo hướng dẫn của htop, bước đầu là cài một library cùng vài tool compile:

sudo apt install libncursesw5-dev build-essential

Tên package libncursesw5-dev bắt đầu bằng lib và kết thúc bằng -dev, dấu hiệu cho thấy đây là package chứa một library dùng cho mục đích phát triển. Code của htop dựa vào library này để vẽ giao diện ứng dụng. Package build-essential thì gần như lúc nào cũng cần, vì nó kéo vào phần lớn các tool compile cần thiết.

Xem lại thư mục sẽ thấy một file thực thi được đánh dấu màu xanh lá, tên autogen.sh. File README hướng dẫn chạy nó. Để thực thi shell script này, gõ ./ để bảo bash shell rằng cần chạy một file trong thư mục hiện tại:

./autogen.sh
ls

Lệnh này sinh ra một configuration script. Chạy ls sẽ thấy nó, tên gọn là configure, và nó giúp cấu hình cách build ứng dụng này: bật hoặc tắt tính năng nào của app, cùng nhiều thứ khác:

./configure --help
./configure

Dòng đầu in ra rất nhiều option cấu hình dùng được. Muốn cấu hình với các option mặc định thì chỉ cần chạy script không kèm tham số nào. Ngoài việc cấu hình, script này còn xác minh xem hệ thống có đáp ứng các yêu cầu compile hay không.

make và make install

Để compile và build ra ứng dụng cuối cùng thì dùng utility make. make cũng nhận các tham số bổ sung, nhưng nó hỗ trợ tham số nào thì tùy project đang compile. Để xem các tham số truyền được vào make, dùng lại mẹo đã quen: gõ make, một dấu cách, rồi nhấn Tab hai lần. Ở đây ra 127 khả năng, và chúng được gọi là make target.

Không phải mọi thứ hiện ra đều là target hợp lệ. Nhưng với những cái hợp lệ thì chúng không chỉ dùng được ở đây, chúng còn có mặt trong phần lớn project khác, ví dụ các target clean, distclean, install và uninstall.

make clean hữu ích khi mọi thứ không theo đúng kế hoạch, ví dụ quá trình compile thất bại giữa đường và để lại kết quả dở dang, tức một project build được một nửa. Để dọn sạch mọi thứ rồi bắt đầu lại thì chạy make clean, rồi sửa vấn đề và compile lại project.

Nếu chỉ cần compile và build app thì chạy make không kèm tham số:

make
ls

Xem lại thư mục sẽ thấy file thực thi htop đã được compile thành một binary, và chạy được bằng:

./htop

Nhấn q để thoát app. Nhưng cách này có điểm bất lợi: mỗi lần dùng utility phải gõ đường dẫn tương đối hoặc đường dẫn đầy đủ tới nó. Đứng ở thư mục khác thì phải chạy /home/jeremy/htop/htop mới khởi động được ứng dụng này, khá bất tiện.

Vì vậy có thể chỉ thị cho make cài ứng dụng vào một thư mục chuyên dụng:

sudo make install
htop

File binary htop được chuyển vào thư mục /usr/local/bin. Từ nay mỗi lần cần chạy app, chỉ cần gõ htop, đứng ở đâu cũng được. Lý do: theo mặc định, shell của mọi user trên hệ thống Ubuntu đều được cấu hình để tìm ứng dụng cả trong thư mục /usr/local/bin, nên không phải gõ đường dẫn đầy đủ tới utility nữa.

---

Nguồn tham khảo

Nguồn gốc: Khóa "Prep Course - Linux Foundation Certified System Administrator (LFCS) Certification" — phần "Operations Deployment" (lập lịch task chạy vào thời điểm đã định với cron, anacron và at; thay đổi kernel runtime parameter bền vững và không bền vững; cài và quản lý software trên Ubuntu bằng apt; cấu hình repository của package manager; cài software từ source code), nền tảng KodeKloud. Giảng viên: Jeremy Morgan và Alexandru Andrei.

Fact-check:

• net.ipv6.conf.all.disable_ipv6 đặt bằng 1 mới là tắt IPv6; giá trị 0 nghĩa là không tắt. Kiểm trên một máy đang chạy IPv6 bình thường thì parameter này đọc ra 0. Bài giảng gốc nói ngược. Nguồn: đo bằng sysctl net.ipv6.conf.all.disable_ipv6 cùng ip -6 addr, 2026-10-25.
• Option -p của sysctl là dạng ngắn của --load, nghĩa là nạp cấu hình từ file. Bài giảng gốc tự đặt cách nhớ "permanent file" và có nói rõ man page không giải thích chữ cái này, nên đó là mẹo nhớ cá nhân chứ không phải hành vi được tài liệu hóa. Nguồn: man 8 sysctl, 2026-10-25.
• Flag tạo archive .tar.gz là tar -czf (-c create, -z gzip, -f file). Bài giảng gốc chỉ đọc tên lệnh liệt kê tar tf chứ không đọc flag tạo. Nguồn: man 1 tar, 2026-10-25.