• news
  • pics
  • linux
  • windows
  • proxmox
  • game
  • news
  • pics
  • linux
  • windows
  • proxmox
  • game

紧身胶衣问谁看不下贱?“HK416”:真的不鼓包的哦!~…

April 12th, 2022

Using local directory bind mount points

February 28th, 2022

Bind mount points are directories on the host machine mapped into a container using the Proxmox framework. It is not (yet) possible to create bind mounts through the web GUI, you can create them either by using pct as

pct set 100 -mp0 /mnt/bindmounts/shared,mp=/shared

or changing the relevant config file, say, /etc/pve/lxc/1234.conf as

mp0: /mnt/bindmounts/shared,mp=/shared

However you will soon realise that every file and directory will be mapped to “nobody” (uid 65534), which is fine as long as

  • you do not have restricted permissions set (only group / user readable files, or accessed directories), and
  • you do not want to write files using a specific uid/gid, since all files will be created using the high-mapped (100000+) uids.

Sometimes this isn’t acceptable, like using a shared, host mapped NFS directory using specific UIDs. In this case you want to access the directory with the same – unprivileged – uid as it’s using on other machines. You need to change the mapping.

Let’s see an example, we want to make uid 1005 accessible in an unprivileged container.

First, we have to change the container UID mapping in the file /etc/pve/lxc/1234.conf:

# uid map: from uid 0 map 1005 uids (in the ct) to the range starting 100000 (on the host), so 0..1004 (ct) → 100000..101004 (host)
lxc.idmap = u 0 100000 1005
lxc.idmap = g 0 100000 1005
# we map 1 uid starting from uid 1005 onto 1005, so 1005 → 1005
lxc.idmap = u 1005 1005 1
lxc.idmap = g 1005 1005 1
# we map the rest of 65535 from 1006 upto 101006, so 1006..65535 → 101006..165535
lxc.idmap = u 1006 101006 64530
lxc.idmap = g 1006 101006 64530

Then we have to allow lxc to actually do the mapping on the host. Since lxc creates the CT using root, we have to allow root to use these uids in the container.

First the file /etc/subuid (we allow 1 piece of uid starting from 1005):

root:1005:1

then /etc/subgid:

root:1005:1

As a final step, remember to change to owner of the bind mount point directory on the host, to match the uid and gid that were made accessible to the container:

chown -R 1005:1005 /mnt/bindmounts/shared

You can start or restart the container here, it should start and see /shared mapped from the host directory /mnt/bindmounts/shared, all uids will be mapped to 65534:65534 except 1005, which would be seen (and written) as 1005:1005.

Proxmox中Lxc容器挂载远程目录

February 28th, 2022

我们有一台PVE,PVE上有个LXC容器(我的是Archlinux),现在我需要把远程目录挂载到Archlinux中。

思路

  1. LXC是特权容器:按Linux常规挂载即可
  2. LXC不是特权容器:远程目录挂载到PVE,通过PVE和LXC目录映射

方案(仅思路2)

  1. 获取Archllinux中用户的uid、gid(一般为1000,1000)
  2. 获取PVE与LXC中uid、gid映射起始值
>>> cat /var/lib/lxc/your_lxc_id/config | grep idmap                                                                                   17:41.49 Wed Jan 26 2022 >>> 
lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536

3. mount命令中的uid、gid 等于 lxc 容器中uid、gid (即1000,1000)加上 pve与lxc映射值(即100000,100000)等于 101000,101000

4. 在pve中mount好远程目录

sudo mount.cifs -o "rw,dir_mode=0777,file_mode=0777,username=yoursmbusername,password=yoursmbpassword,uid=101000,gid=101000" //remote_ip //mount_point

5. 在LXC容器中创建好映射目录

6. 修改LXC容器的配置文件 `nano /etc/pve/lxc/yourlxcid.conf` ,新增一行

lxc.mount.entry: /pve_mount_point  lxc_mount_point none rw,bind 0 0

注意,lxc_mount_point 是相对根目录路径

livego流媒体服务实现无插件播放视频(支持hls,flv)

February 26th, 2022

一:简述
本文将描述如何使用livego配合flv.js 和hls.js 实现无插件的播放视频流。可以同时支持安卓、ios、PC端浏览器拉流。本示例所有的执行结果是windows下试验的。flvjs和hlsjs需要使用谷歌浏览器或者360浏览器极速模式可以访问。文章如有错误或者有什么更好的方式望大佬们指出相互学。感谢各位贡献出源码的大佬们。

二:环境准备
下载livego。编译好二进制文件下载路径 https://github.com/gwuhaolin/livego/releases)
下载flv的js和hls的js文件,下图是我上传的资源文件的目录结构。是我们需要用到的一些文件 下载

下载编译好的livego可以实现推送rtmp的流转换成http的flv的视频流。但是再转换hls的视频流的地方有一个小bug。需要稍微改进一下。如果需要使用到hls的视频流。建议自己重新编译一下livego的源码。我自己重新编译了下livego的源码。可以直接 下载(如下载我编译好的文件。可以直接启动里面的程序。可以忽略livego源码编译部分)
三:编译livego源码
下载livego源码 https://github.com/gwuhaolin/livego.git

下载完成后,解压文件。源码的目录结构如下。将源代码放置
GOPATH所在目录下的src目录。使用goland的编辑器。会自动识别src目录下的代码。

livego的源码导入的包很多是引入了gitbug上面的包。如果编译不能找到对应的包的话。可以将github上的导入包修改指定导入本地的包。导入包的目录是以GOPATH目录下的src目录为开始目录。所以目录结构应该是从livego/开始。可以按照此方式修改到本地。需改修改的地方很多,可以根据编译错误提示修改。修改完成后直接编译就可以了。或者使用命令行到对应目录下执行 go build livego.go 命令。

在推送视频流到livego的过程中。一直都是直接使用没有细细研究过其中的代码。由于后来项目中需要在苹果手机中播放视频流。总是播放hls的视频流失败。而安卓手机使用hls的js可以播放。即使如此安卓手机使用hls的js播放视频流也很不稳定。有些视频流可以有些流又不可以。我一度怀疑是不是自己的视频流的格式推送的又问题。后来无奈只好调试livego的程序。发现浏览器在向livego的服务请求视频流的时候,解析hls的视频流的路径出现了一个小bug。这也是go语言的函数中的一个小bug。hls.go文件里面解析路径出现了错误。strings.TrimRight的出的问题。直接修改代码去除后缀。
修改代码如下:
源码目录:livego\protocol\hls\hls.go 155行。修改一个函数。还修改了hls的延迟时间修改为1s
key = strings.TrimRight(pathstr, path.Ext(pathstr)) 修改代码如下
key = strings.TrimSuffix(pathstr, path.Ext(pathstr))
修改hls.go 18行。将duration 改为1000 减少hls的延迟

代码修改完成后,在使用命令go build livego就可以直接编译运行了。在goland的比编译器中直接运行。会提示找不到配置文件。因为livego需要读取配置文件livego.cfg.或者修改程序获取程序运行的当前路径。可以在编译器中直接运行。

四:使用ffmpeg推送视频流
我上传的资源文件里面包含了ffmpeg库

使用ffmpeg推送本地的视频文件到livego。需要提醒的是:livego默认读取的配置文件里面livego.cfg文件

{undefined
“server”: [
{undefined
“appname”:”live”,
“liveon”:”on”,
“hlson”:”on”
}
]
}

推送的视频流路径前缀必须是 rtmp://IP:1935/live/.否在livego不识别该路径。可以根据自己需要手动改写这个appname的值。下面给出使用ffmpeg命令推送、拉流的命令:

推送本地的文件到livego: 双击pushvideofile.bat文件就可以直接推送视频流了。(需要先启动livego)

ffmpeg -re -i %filepath%\video\Apache.mp4 -vcodec libx264 -acodec aac -f flv rtmp://127.0.0.1:1935/live/stream

推送rtsp的流到livego:

ffmpeg -re -rtsp_transport tcp -i “rtsp://admin:[email protected]:554/media/video1” -f flv -vcodec copy -vprofile baseline -acodec copy -ar 44100 -strict -2 -ac 1 -f flv -q 10 “rtmp://101.132.162.72:1935/live/stream”

拉流路径:

RTMP:rtmp://localhost:1935/live/stream
FLV:http://127.0.0.1:7001/live/stream.flv
HLS:http://127.0.0.1:7002/live/stream.m3u8

可以先使用ffplay去播放三种视频流。确定视频流是否已经推送到livego中。我资源文件中都上传了对应的bat执行命令。双击即可。下图是我推送的一个本地文件,使用三种方式拉的视频流。可以看出hls的流明显比flv和rtmp的慢一些

五:使用flvjs和hlsjs播放视频流
成功推送视频流至livego中后。可以使用flvjs和hlsjs播放视频流。下面将使用谷歌浏览器和360浏览器极速模式获取的flv的视频流:

修改flvjs和hlsjs的demo中index.html对应的视频流的路径::

flv的js:修改index.html 67行对应得 url: ‘http://127.0.0.1:7001/live/unv.flv’, //<==自行修改
修改需要播放得flv视频得url。flv.js得参数细节这里不作描述。可以自己上网查询。

hls的js:修改index.html 15行
修改需要播放得hls视频得url。即可。苹果手机不需要js得支持。可以直接在原生得浏览器中输入http的流得地址即可播放。

谷歌浏览器播放flv的视频:

360浏览器极速模式播放flv的视频流:hls的流可以按照相应的方式修改。这里就不做详述了。

2020-04-19:

uuid.go的源文件也需要更改

/utils/uid/uuid.go:9:18: multiple-value uuid.NewV4() in single-value context

将报错文件第9行

id := uuid.NewV4() 改成 id,_ := uuid.NewV4()

livego-0.0.5的版本不是很稳定。不推荐大家使用
————————————————
版权声明:本文为CSDN博主「越老越顽固」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_37103755/article/details/102870307

PVE直通核显给虚拟机

February 15th, 2022

本教程在6.0测试通过

检查CPU是否支持VT-d:

https://ark.intel.com/content/www/cn/zh/ark.html

找到下面这项,显示是表示支持:

虚拟机创建的时候注意一下4点:

不要设置开机自启动

如果只是直通核显设备,不要像网上那些教程那样改什么BIOS和Machine,保持和下图一样的默认就行:

 一般直通GPU给虚拟机,虚拟机都是用Windows吧,我发现Proxmox上装Windows硬盘的总线/设备改为IDE,格式改为Raw的性能是最好的,另外如果宿主机是单盘(没有RAID阵列)就不要设置Writeback模式了,默认的最好:

CPU的模式选择Host,即尽量保证虚拟机内的CPU指令集和宿主机内一致。

现在配置直通相关的东西。

首先编辑GRUB配置文件:

nano /etc/default/grub

开启IOMMU支持:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on video=efifb:off"

如果是AMD的CPU:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on video=efifb:off"

更新GRUB:

update-grub

添加所需的系统模块(驱动):

echo "vfio" >> /etc/modules
echo "vfio_iommu_type1" >> /etc/modules
echo "vfio_pci" >> /etc/modules
echo "vfio_virqfd" >> /etc/modules

接着添加模块(驱动)黑名单,即让GPU设备在下次系统启动之后不使用这些驱动,把设备腾出来给vfio驱动用:

Intel核显:

echo "blacklist snd_hda_intel" >> /etc/modprobe.d/pve-blacklist.conf
echo "blacklist snd_hda_codec_hdmi" >> /etc/modprobe.d/pve-blacklist.conf
echo "blacklist i915" >> /etc/modprobe.d/pve-blacklist.conf

N卡/A卡:

echo "blacklist nouveau" >> /etc/modprobe.d/pve-blacklist.conf
echo "blacklist radeon" >> /etc/modprobe.d/pve-blacklist.conf

如果是N卡还需要加入下面的配置到kvm.conf(据老外说是避免一些莫名其妙的错误):

echo "options kvm ignore_msrs=1" > /etc/modprobe.d/kvm.conf

更新内核:

update-initramfs -u

重启机器:

reboot

重启上来之后检查模块是否正常加载:

lsmod | grep vfio

有类似回显说明正常:

vfio_pci               45056  1vfio_virqfd            16384  1 vfio_pci
irqbypass              16384  13 vfio_pci,kvm
vfio_iommu_type1       24576  1vfio                   28672  5 vfio_iommu_type1,vfio_pci

查看GPU设备ID:

lspci -nn | grep VGA

类似我的回显:

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06)

再执行下面的命令:

lspci -vvv -s 00:02.0

看有没有Kernel driver in use这一行,正常情况下应该是没有的。

如果有那么就说明你之前肯定是哪里没配置好(一般是i915的驱动没屏蔽成功)。

直通完成后的截图:

现在把需要直通给虚拟机的设备ID写到vfio.conf内,注意这次这里的ID不是00:02.0而是自己查看自己设备的ID,ID查看在上面回显里:

echo "options vfio-pci ids=8086:1912" >> /etc/modprobe.d/vfio.conf

回到Proxmox的WEB界面,给需要直通GPU的虚拟机添加对应的PCI设备:

切记直通核显不要勾选这个主GPU的选项:

给虚拟机开机,先用VNC登录进去,登录进去之后开启RDP,然后退出来用远程桌面去登录。

之后去Inter的官网下载对应的驱动程序:

https://downloadcenter.intel.com/zh-cn/product/80939/-

我的系统win10,CPU i5-8400 核显630 下载对应驱动

直通完成:

Proxmox random crash : Inserted module 'iscsi_tcp'

February 12th, 2022

Each time of crash, the sequence of logs are beginning with :
Code:

"pve1 systemd-modules-load[1913]: Inserted module 'iscsi_tcp'"

To fix it disabled the loading of this module
edited the file :
Code:

/lib/modules-load.d/open-iscsi.conf

And commented the two lines (to be sure to fix the problem) :
Code:

#iscsi_tcp
#ib_iser

And then restarted the service with :
Code:

systemctl restart systemd-modules-load.service

And checked that the service is running with :
Code:

systemctl status systemd-modules-load.service

windows和linux下读取文件换行符的一个坑——\r\n和\n

January 12th, 2022

假设Windows上有一个dos.txt文件, 那么, 它在文件中的换行标志是\r\n, 现在拷贝到linux下, 那好啊, 正如linus一样, linux这个倔强的家伙貌似在说: 别的我不管, 我遇到文件中的\n, 我就认为是换行, 至于其他的, 我只认为是正常的字符。 如此一来, \r就被当成了文件的正常部分, 也就是说, linux下的C程序不仅仅会读取到\n, 也会读取到它前面的\r.

   实际上Windows上的文件是dos格式的, 而linux上的文件是unix格式的, 我们可以通过linux上的dos2unix和unix2dos来实现转化, 当然, 有的linux环境下, 需要用busybox dos2unix和busybox unix2dos.

shell 中 [-eq] [-ne] [-gt] [-lt] [ge] [le]

January 12th, 2022

-eq           //等于

-ne           //不等于

-gt            //大于 (greater )

-lt            //小于  (less)

-ge            //大于等于

-le            //小于等于

命令的逻辑关系:

在linux 中 命令执行状态:0 为真,其他为假

逻辑与: &&
第一个条件为假时,第二条件不用再判断,最终结果已经有;
第一个条件为真时,第二条件必须得判断;
逻辑或: ||
逻辑非: !

crontab执行时间与系统时间不一致问题解决

December 27th, 2021

前言

在LINUX中,周期执行的任务一般由cron这个守护进程来处理[ps -ef|grep cron]。cron读取一个或多个配置文件,这些配置文件中包含了命令行及其调用时间。

cron的配置文件称为“crontab”,是“cron table”的简写。

cron是一个linux下 的定时执行工具,可以在无需人工干预的情况下运行作业。

  service crond start //启动服务
  service crond stop //关闭服务
  service crond restart //重启服务
  service crond reload //重新载入配置
  service crond status //查看服务状态 

发现问题 

事情是这样的在自己的服务上有一条如下crontab

110 0 * * * root echo 'xxx' >> zzz

熟悉的人都知道是 晚上00:10执行,把xxx输出到zzz文件

可是问题来了 这条crontab不在00:10执行!而是在中午12:10执行。

crontab 执行时间和系统时间不一致!!!!

我记得服务器更改过时区现在也是 CST时区 没理由不执行啊!

试着google下crontab 时区,还真搜到 几个类似的例子

原来 修改过时间后必须手动重启crontab

1/etc/init.d/crond restart

必须重启crontab 重启服务器是没有用的,我修改时区后重启过服务器 都是没有用的,必须重启crontab!

还有一种情况的 时区分两个 一个是 timezone 还有个是localtime,按照下面命令即可解决

1
2
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
service crond restart

Failed to restart crond.service: Unit crond.service not found.

December 21st, 2021

because on ubuntu the service named cron.not crond

Page 2 of 381234...
Meta
  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org
Categories
  • game
  • linux
  • news
  • pics
  • proxmox
  • windows
Recent Posts
  • Proxmox VE 直通显卡方案及解决N卡Code43
  • Linux系统出现:You have new mail in /var/spool/mail/root 的原因及解决办法
  • debian系统解决中文乱码
  • pve添加git和pvetools
  • 流鼻血!这不“枣糕”的傲人身材加体现了出来~
Recent Comments
  • Paulvem on Proxmox VE 直通显卡方案及解决N卡Code43
  • Davidimmip on Proxmox VE 直通显卡方案及解决N卡Code43
  • Jimvem on Proxmox VE 直通显卡方案及解决N卡Code43
  • MichaelNat on Proxmox VE 直通显卡方案及解决N卡Code43
  • MiclBiG on Proxmox VE 直通显卡方案及解决N卡Code43
Archives
  • December 2022 (4)
  • November 2022 (6)
  • April 2022 (1)
  • February 2022 (5)
  • January 2022 (2)
  • December 2021 (3)
  • November 2021 (1)
  • October 2021 (2)
  • September 2021 (1)
  • August 2021 (1)
  • July 2021 (8)
  • June 2021 (14)
  • May 2021 (2)
  • April 2021 (2)
  • March 2021 (10)
  • January 2021 (4)
  • December 2020 (4)
  • November 2020 (13)
  • April 2020 (276)
  • March 2020 (1)
  • June 2019 (5)
  • May 2019 (10)
  • December 2015 (1)