Benefit #

One benefit is if a newer version of Podman is released with fixes or enhancements to the generator, your service is updated with the enhanced version the next time systemctl daemon-reload executes, such as upon reboot.

The container descriptions focus on the relevant container details, with no technical details about how the Podman integration works. This means they are straightforward to write and maintain, and integration can automatically improve as new Podman features become available. Now you can use the other cool features of Podman in systemd, like auto-update and rollback, for hands-free management of your containerized service’s lifecycle.

Content #

Listen to this review, “While their service could use some work, the signature dishes at this restaurant more than make up for any issues.”

more than: 表示强调，可翻译为非常、极其。 while their service could use some work: 尽管他们的服务还有待改进。 The dining experience here is more than satisfactory, especially when you try their signature dish, the beef Wellington.

From #

Links #

Log Driver #

Log Driver Options #

1. journald Use systemd journal to store logging information Persist logs after container removal: Yes Log Rotation: No
2. k8s-file Store logging data in Kubernetes format flat file Persist logs after container removal: No Log Rotation: No
3. None Do not store any logging information Persist logs after container removal: No Log Rotation: No

see the default log driver #

$ podman info --format '{{ .Host.LogDriver }}'

set to log to k8s-file #

$ mkdir -p $HOME/.config/containers/containers.conf.d
$ cat > $HOME/.config/containers/containers.conf.d/log_driver.conf << _EOF
[containers]
log_driver="journald"
_EOF
$ podman info --format '{{ .Host.LogDriver }}'
journald

Check if log persists:

Content #

./cursor-0.41.2x86_64.AppImage –appimage-extract

sudo chown root:root squashfs-root/chrome-sandbox sudo chmod 4755 squashfs-root/chrome-sandbox

./squashfs-root/AppRun

From #

Links #

Content #

Log Driver(Podman)

Quadlet #

用下面的命令检查container文件的格式是否正确：

/usr/libexec/podman/quadlet --dryrun

User Namespace #

In your container, the Apache Web Server process (httpd) is run as the apache (UID==60) user. The html directory in your home directory is owned by your UID, meaning it is owned by root inside the container.

In rootless containers, the UIDs of the container are offset by the user namespace. My user namespace mapping looks like this:

Content #

fuser -n tcp|udp -v <port number>[, <remote address>[, <remote port>]]

比如：

fuser -n tcp -v 515

From #

Links #

Content #

DHCP交互过程 DHCP续租过程

From #

Links #

客户端获取 IP 后的续租 #

当客户端快要达到租约期时，它会向服务器发送 DHCP Request 续租，而这时它已经有了 IP，因此数据包格式略有不同：

DHCP Request（续租） #

源 IP 192.168.1.100（客户端已有 IP）目标 IP 192.168.1.1（DHCP 服务器）源端口 68（DHCP 客户端）目标端口 67（DHCP 服务器）说明：客户端不再使用广播，而是直接单播到服务器请求续租。

DHCP ACK（续租确认） #

字段 值源 IP 192.168.1.1（DHCP 服务器）目标 IP 192.168.1.100（客户端）源端口 67（DHCP 服务器）目标端口 68（DHCP 客户端）说明：服务器直接向客户端的 IP 发送确认信息，完成续租。

From #

Links #

Content #

设备信息： DHCP 服务器：192.168.1.1 客户端（初始无 IP）：最终获取 192.168.1.100

1）DHCP Discover —— 客户端发现服务器 #

客户端（无 IP）需要一个 IP 地址，因此它发送 DHCP Discover 广播包。

源 IP 0.0.0.0（客户端尚无 IP）目标 IP 255.255.255.255（广播）源端口 68（DHCP 客户端）目标端口 67（DHCP 服务器）说明：客户端无法确定 DHCP 服务器的 IP，因此使用广播地址 255.255.255.255 发送请求。

2）DHCP Offer —— 服务器提供 IP #

DHCP 服务器响应客户端的请求，提供可用 IP 地址。

源 IP 192.168.1.1（DHCP 服务器）目标 IP 255.255.255.255（广播）源端口 67（DHCP 服务器）目标端口 68（DHCP 客户端）说明：虽然服务器知道客户端的 MAC 地址，但它尚未有 IP，因此仍然用广播发送。

3）DHCP Request —— 客户端请求 IP #

客户端选择一个 DHCP 服务器（如果收到多个 Offer），然后发送 DHCP Request 请求该 IP。

Content #

Linux 网络栈优化： #

本机地址的包不会真的发往网络再回来，而是直接通过回环接口（loopback, lo） 处理。

假设你的外部 IP 地址是 203.0.113.10，你执行：

ping 203.0.113.10

你可能以为数据包会经由外部接口发送出去，再通过互联网返回。但实际上，Linux 网络栈知道这个 IP 属于本机，所以它会直接将数据包路由到回环接口（lo），不会真正离开你的设备。

防止伪造攻击的逻辑： #

你的机器不会从外部接口收到一个伪造的、声称来自本机的 IP 数据包，因为它根本不会经过外部网络。这意味着你不需要特别阻止目的地址是你自己的出站流量，因为它不会“绕一圈”回来。

From #

Links #