Articles of Debian

在Debian 8 dist-upgrade之后,Hyper-V丢失了合成NIC?

我在Hyper-V上运行Debian 8 vm(Win Srv 2012R2),当我做了稳定的升级时,我失去了所有的networking连接。 使用控制台,我能够看到networking接口为UP,但无法ping任何外部地址。 dist-upgrade将内核升级到了linux-image-3.16.0-4-686-pae(3.16.7-ckt11-1 + deb8u2)。 我能够通过添加2个传统的networking接口来解决这个问题,这个networking接口被这个新的内核所识别,但是性能却大大降低了。 Hyper-V模块似乎被加载得很好: root@rproxy3:~# lsmod | fgrep hv_ hv_utils 17454 0 hv_netvsc 30069 0 hv_storvsc 17048 2 hv_vmbus 27978 6 hyperv_keyboard,hv_netvsc,hid_hyperv,hv_utils,hyperv_fb,hv_storvsc scsi_mod 164132 5 sg,libata,sd_mod,sr_mod,hv_storvsc root@rproxy3:~# dmesg | fgrep hv_ [ 1.303529] hv_vmbus: Hyper-V Host Build:9200-6.2-16-0.16729; Vmbus version:2.4 [ 1.336977] hv_vmbus: registering driver hv_storvsc [ 1.343214] hv_vmbus: […]

钩入Debian软件包的安装

在使用守护进程安装软件包时,他们经常在Debian上安装/升级时重新启动该服务。 我有一个守护进程,它有一些只能在运​​行时设置的选项,没有configuration。 如果Debian软件包在我的控制之下,我会更改init脚本,以便它包含一个函数来设置这些选项,并在(重新)启动服务之后调用它。 由于这个守护进程来自一个远程仓库,我不想build立我自己的deb,所以我需要一个解决scheme,不会改变包中的任何文件(以避免在通过dpkg / apt更新包时出现问题)。 那么,是否有可能在该服务重新启动后以干净的方式执行某些命令或脚本?

replaceDebian上的scponly

已经从Debian软件包中删除了 scponly。 我正在使用scp来从Debian 8服务器和先前的Debian服务器上scponly备份,我已经设置了loginshell来scponly以限制备份用户。 什么是scponly的好替代shell,或者什么样的configuration可以使sshd提供相当于scponly的安全性?

带有SRS守护进程的exim4configuration

我正在使用外部SRS守护进程(Debian软件包srs)设置exim 4。 srsd正在运行,并且将地址前后转换就好了。 我不能使用exim的内置srs代码,因为它在Debian中没有启用(知道我可以编译自己,但它不是一个选项)。 我遇到的问题是exim中的srs_forward路由器添加SRS标签到转发邮件。 我有下面的redirect路由器的地方,应该只运行非本地发件人和非本地收件人,这是不中继为另一个MX的错误消息 – 至less我明白srs将应用于这样的消息。 如果这是错的,请纠正我。 我有以下代码: srs_forward: debug_print = "R: srs_forward for $local_part@$domain" driver = redirect senders = ! : condition = ${if ! match_domain{$sender_address_domain}{+local_domains}} domains = ! +local_domains : ! +relay_to_domains address_data = ${readsocket{/tmp/srsd}\ {FORWARD $sender_address_local_part@$sender_address_domain $domain\n}\ {5s}{\n}{:defer: SRS daemon failure}} errors_to = ${quote_local_part:${local_part:$address_data}}@${domain:$address_data} data = ${quote_local_part:$local_part}@$domain headers_add = X-SRS: […]

在内核BUG上自动重启(不受污染,“修复recursion故障,但需要重新启动”)

我正在XenServer 6.2主机上运行一个高负载的Debian 7 VM和最新的3.2.x内核。 有时这个虚拟机运行到以下状态: 平安无事,所有服务无法访问(包括SSH) 显示一条消息显示trace +“内核错误” 进一步在错误消息下面显示“修复recursion故障但需要重新启动” sysctl kernel.panic=1已经设置。 这在这种情况下不起作用。 机器不重新启动。 这样的故障后,怎么可能让机器自行重启(因为这不是OOPS,对吗?)? 理想情况下,在重新启动文件系统和ro mount的同步之前会很好… 我知道SysRQ,但我正在寻找一种解决scheme,无需人工干预即可正常工作。 谢谢! 🙂

不支持mount.cifs操作,但smbclient按预期方式连接

当使用mount.cifs ver在Debian 8.2上安装OSX 10.9.5共享时 6.4: mount error(95): Operation not supported 证书不是问题。 我可以通过smbclient访问它们。 Mount正确读取凭证文件中的域和用户名。 我以root身份运行,所以希望没有权限问题。 我能find的唯一区别是在文件共享主机上的/var/log/system.log报告的标志。 访问mount.cifs列出没有标志, smbclient列出了一些。 但mount.cifs在另一台机器(archlinux)上工作,也没有标志。 # smb client works fine smbclient \\\\arnold\\T800 -A ~ni_tools/passwd/arnold Domain=[ARNOLD] OS=[Darwin] Server=[@(#)PROGRAM:smbd PROJECT:smbx-276.92.2] smb: \> # mount sudo mount -t cifs //arnold/T800 test -o credentials=~ni_tools/passwd/arnold,iocharset=utf8,uid=1000,gid=1000,rw -vv domain=ARNOLD mount.cifs kernel mount options: ip=157.229.27.130,unc=\\arnold\T800,iocharset=utf8,uid=1000,gid=1000,user=lncd,,domain=ARNOLD,pass=******** mount error(95): Operation not supported […]

crm_mon -E不会在Debian Jessie上运行外部代理

build立 我目前正在使用Pacemaker + Corosync工作的2节点HA集群。 我的节点运行在Debian 8(Jessie)上。 现在,当集群发生更改(资源停止/启动,升级/降级,移动…)时,我将能够得到通知。 由于电子邮件报告是如此,2008年,我想使用Slack。 为此,我创build了一个脚本,使用curl将消息发布到我的团队的Slack频道,使用Slack的webhook 。 我的脚本使用了这里logging的环境variables: Pacemaker – 7.3。 通过外部代理configuration通知 。 该脚本在shell中手动执行时可以正常工作,并且能够在指定的通道上发布。 它也logging到/var/log/ocf-notifier.log 。 问题 基于这个答案 ,我使用Pacemaker的ocf:pacemaker:ClusterMon创build了一个新的资源ocf:pacemaker:ClusterMon资源代理,它调用我的自定义脚本( /usr/local/bin/ocf-notifier )。 但是我注意到,当节点发生更改时(尝试停止资源以及完全closures节点),根本不调用我的脚本。 所以我试图用手工启动crm_mon ,如下所示: $ crm_mon -Arf –interval=2 -E /usr/local/bin/ocf-notifier -e '@jordan' 看看是否可以通过与另一个shell一起玩群集来触发这个事情。 事实certificate, crm_mon能够看到集群中发生的变化(节点脱机,资源被停止/启动…),但我的自定义脚本从来没有眨眼之间。 我的自定义日志文件保持空白,Slack中没有任何内容,因为我相信这个脚本根本就没有被调用。 TL; DR crm_mon不会在集群事件上调用外部代理,因为它应该与-E选项一起使用。 我究竟做错了什么?

apt更新被周期性closures阻塞

我有Debian在一个VPS实例上运行,这个实例对于一个小型用户群不定期使用的一个小站点/项目来说是活着的。 服务器很大程度上是孤立的,但我试图login每个时间,然后保持包最新。 今天,我意识到,我已经有很长一段时间没有在服务器上login,并运行apt-get update && apt-get upgrade 。 除了有大量可用更新的软件包外,事情似乎一切顺利,直到升级过程突然停止,并显示以下消息: Processing triggers for man-db … Errors were encountered while processing: /var/cache/apt/archives/mime-support_3.58_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) 第二次运行apt-get upgrade表明大部分要更新的软件包都被“mime-support”保留。 Preparing to replace mime-support 3.48-1 (using …/mime-support_3.58_all.deb) … dpkg: error processing /var/cache/apt/archives/mime-support_3.58_all.deb (–unpack): triggers ci file contains unknown directive `interest-noawait' configured to not write apport […]

具有多个networking接口和不同子网的DHCP服务器

我试图在4个networking接口eth0-3上设置一个dhcp服务器(在debian 8上的isc dhcpd(在esxi环境中的vm))。 dhcp服务器应该在接口eth1 , eth2 , eth3上提供不同的子网。 每个子网都有自己的vSwitch(vSphere),dhcp服务器连接到每个vSwitch。 networking接口设置如下所示: source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 auto eth1 iface eth1 inet static address 10.0.0.1 netmask 255.255.255.0 network […]

Linux上的VRF使用networking命名空间

我的最终目标是在Linux中实现虚拟路由和转发(VRF)。 似乎被广泛接受的方法是设置不同的networking名称空间(每个单独的路由表一个),并为每个名称空间/路由表运行一个Quagga或BIRD守护进程。 我没有结婚这个方法,所以如果有人有任何其他的build议,请让我知道。 有问题的机器在VMware工作站12中运行Debian 7(wheezy)。它一直是一个路由器,并且在我开始重新configuration之前已经成功路由了一段时间,所以我知道一般的路由设置是好的。 目前的问题是我无法通过我的networking名称空间进行通信。 也就是说,veth1(这是在我的名字空间如下)只能ping veth0,没有别的。 veth1和它下面的networking之间没有networking通信 – 甚至没有ARP。 如果我不知道更好的话,我会说有人从交换机上拔下了电缆(但在虚拟环境中很难做到这一点)。 是的,我检查了vmnets设置正确。 路由器在恢复到旧configuration时工作。 这只是在这个新的configuration不起作用。 任何人有任何想法如何获得veth1沟通? 甚至是完全不同的方法来获得VRF在Linux上的工作? 提前致谢。 我build立了新的configuration如下: 添加命名空间 ip netns add nsx 添加虚拟接口 ip link add veth0 type veth peer name veth1 创造一座桥梁 ip link add name vbr0 type bridge 将eth1和veth1添加到桥 ip link set dev eth1 master vbr0 ip link set dev veth1 […]