主页 / user-5922

Kamil Kisiel's questions

Martin Hope
Kamil Kisiel
Asked: 2010-03-30 09:30:10 +0800 CST
  • 2

当用户从他们的 OS X (Snow Leopard) 工作站通过 SSH 连接到我们的一台 Linux 主机时，他们会时不时地收到以下消息：

/usr/bin/xauth: ~/.Xauthority not writable, changes will be ignored

当然，此时他们的 X 转发应用程序将不起作用。

但是，如果他们注销并重新登录，他们不会收到消息，并且一切都按预期工作。

在他们的 Mac 上，他们通过 AFP 获得他们的主目录。Linux 机器通过 NFS 获取它。

关于这里可能发生什么的任何想法？

linux mac-osx x11
Martin Hope
Kamil Kisiel
Asked: 2010-03-02 09:57:46 +0800 CST
  • 1

有没有办法从服务器查看哪些客户端安装了 NFS (v3) 导出？

我认为这showmount -a会显示此信息，但似乎并非如此。它似乎确实显示了已连接客户端的列表，但没有显示它们已安装的导出。

服务器正在运行 SLES 10。

我得到的输出showmount -a是（出于隐私目的删除了一些类似的行）：

All mount points on oneose:
10.0.0.0/8,10.2.128.0/22,netboot.cluster.example.com:/mnt/foo
10.0.0.0/8,10.2.128.0/22,netboot.cluster.example.com:/mnt/project/foo1
10.0.0.0/8,10.2.128.0/22,netboot.cluster.example.com:/mnt/project/foo2
10.0.0.0/8:/mnt/home
10.128.1.2:10.0.0.0/8
10.2.0.65:10.0.0.0/8
10.2.128.0/22:/mnt/project
10.2.128.10:10.0.0.0/8,10.2.128.0/22
10.2.128.30:10.0.0.0/8
10.2.128.30:10.0.0.0/8,10.2.128.0/22
10.2.128.40:10.0.0.0/8
10.2.128.40:10.0.0.0/8,10.2.128.0/22,netboot.cluster.example.com
10.2.128.50:10.0.0.0/8
10.2.129.10:10.0.0.0/8
10.2.129.10:10.0.0.0/8,10.2.128.0/22
10.2.129.11:10.0.0.0/8
10.2.129.11:10.0.0.0/8,10.2.128.0/22
10.2.129.12:10.0.0.0/8
10.2.129.12:10.0.0.0/8,10.2.128.0/22
10.2.129.13:10.0.0.0/8
10.2.129.13:10.0.0.0/8,10.2.128.0/22
10.2.129.14:10.0.0.0/8
10.2.129.14:10.0.0.0/8,10.2.128.0/22
10.2.129.15:10.0.0.0/8
10.2.129.15:10.0.0.0/8,10.2.128.0/22
10.2.129.16:10.0.0.0/8
10.2.129.16:10.0.0.0/8,10.2.128.0/22
10.2.129.17:10.0.0.0/8
10.2.129.17:10.0.0.0/8,10.2.128.0/22
10.2.129.18:10.0.0.0/8
10.2.129.18:10.0.0.0/8,10.2.128.0/22
10.2.129.19:10.0.0.0/8
10.2.129.19:10.0.0.0/8,10.2.128.0/22
10.2.129.20:10.0.0.0/8
10.2.129.20:10.0.0.0/8,10.2.128.0/22
10.2.129.21:10.0.0.0/8
10.2.129.21:10.0.0.0/8,10.2.128.0/22
10.2.129.22:10.0.0.0/8
10.2.129.22:10.0.0.0/8,10.2.128.0/22
10.2.129.23:10.0.0.0/8
10.2.129.23:10.0.0.0/8,10.2.128.0/22
10.2.129.24:10.0.0.0/8
10.2.129.24:10.0.0.0/8,10.2.128.0/22
10.2.129.25:10.0.0.0/8
10.2.129.25:10.0.0.0/8,10.2.128.0/22
10.2.129.26:10.0.0.0/8
10.2.129.26:10.0.0.0/8,10.2.128.0/22
10.2.129.27:10.0.0.0/8
10.2.129.27:10.0.0.0/8,10.2.128.0/22
10.2.129.28:10.0.0.0/8
10.2.129.28:10.0.0.0/8,10.2.128.0/22
10.2.129.29:10.0.0.0/8
10.2.129.29:10.0.0.0/8,10.2.128.0/22
10.2.129.30:10.0.0.0/8
10.2.129.30:10.0.0.0/8,10.2.128.0/22
10.2.129.31:10.0.0.0/8
10.2.129.31:10.0.0.0/8,10.2.128.0/22
10.2.129.32:10.0.0.0/8
10.2.129.32:10.0.0.0/8,10.2.128.0/22
10.2.129.33:10.0.0.0/8
10.2.129.33:10.0.0.0/8,10.2.128.0/22
10.2.129.34:10.0.0.0/8
10.2.129.34:10.0.0.0/8,10.2.128.0/22
10.2.129.35:10.0.0.0/8
10.2.129.35:10.0.0.0/8,10.2.128.0/22
10.2.129.36:10.0.0.0/8
10.2.129.36:10.0.0.0/8,10.2.128.0/22
10.2.129.37:10.0.0.0/8
10.2.129.37:10.0.0.0/8,10.2.128.0/22
10.2.129.38:10.0.0.0/8
10.2.129.38:10.0.0.0/8,10.2.128.0/22
10.2.129.39:10.0.0.0/8
10.2.129.39:10.0.0.0/8,10.2.128.0/22
10.2.129.40:10.0.0.0/8
10.2.129.40:10.0.0.0/8,10.2.128.0/22
10.2.129.41:10.0.0.0/8
10.2.129.41:10.0.0.0/8,10.2.128.0/22
10.2.129.42:10.0.0.0/8
10.2.129.42:10.0.0.0/8,10.2.128.0/22
10.2.129.43:10.0.0.0/8
10.2.129.43:10.0.0.0/8,10.2.128.0/22
10.2.129.44:10.0.0.0/8
10.2.129.44:10.0.0.0/8,10.2.128.0/22
10.2.129.45:10.0.0.0/8
10.2.129.45:10.0.0.0/8,10.2.128.0/22
10.2.129.46:10.0.0.0/8
10.2.129.46:10.0.0.0/8,10.2.128.0/22
10.2.129.47:10.0.0.0/8
10.2.129.47:10.0.0.0/8,10.2.128.0/22
10.2.129.48:10.0.0.0/8
10.2.129.48:10.0.0.0/8,10.2.128.0/22
10.2.129.49:10.0.0.0/8
10.2.129.49:10.0.0.0/8,10.2.128.0/22
10.2.129.50:10.0.0.0/8
10.2.129.50:10.0.0.0/8,10.2.128.0/22
10.2.129.51:10.0.0.0/8
10.2.129.51:10.0.0.0/8,10.2.128.0/22
10.2.129.52:10.0.0.0/8
10.2.129.52:10.0.0.0/8,10.2.128.0/22
10.2.129.53:10.0.0.0/8
10.2.129.53:10.0.0.0/8,10.2.128.0/22
10.2.129.54:10.0.0.0/8
10.2.129.54:10.0.0.0/8,10.2.128.0/22
10.2.129.55:10.0.0.0/8
10.2.129.55:10.0.0.0/8,10.2.128.0/22
10.2.129.56:10.0.0.0/8
10.2.129.56:10.0.0.0/8,10.2.128.0/22
10.2.129.57:10.0.0.0/8
10.2.129.57:10.0.0.0/8,10.2.128.0/22
10.2.129.58:10.0.0.0/8
10.2.129.58:10.0.0.0/8,10.2.128.0/22
10.2.129.59:10.0.0.0/8
10.2.129.59:10.0.0.0/8,10.2.128.0/22
10.2.129.60:10.0.0.0/8
10.2.129.60:10.0.0.0/8,10.2.128.0/22
10.2.129.60:10.2.128.0/22
10.2.129.61:10.0.0.0/8
10.2.129.61:10.0.0.0/8,10.2.128.0/22
10.2.129.62:10.0.0.0/8
10.2.129.62:10.0.0.0/8,10.2.128.0/22
10.2.129.63:10.0.0.0/8
10.2.129.63:10.0.0.0/8,10.2.128.0/22
10.2.129.64:10.0.0.0/8
10.2.129.64:10.0.0.0/8,10.2.128.0/22
10.2.129.65:10.0.0.0/8
10.2.129.65:10.0.0.0/8,10.2.128.0/22
10.2.129.65:10.2.128.0/22
10.2.129.66:10.0.0.0/8
10.2.129.66:10.0.0.0/8,10.2.128.0/22
10.2.129.66:10.2.128.0/22
10.2.129.67:10.0.0.0/8
10.2.129.67:10.0.0.0/8,10.2.128.0/22
10.2.129.68:10.0.0.0/8
10.2.129.68:10.0.0.0/8,10.2.128.0/22
10.2.129.69:10.0.0.0/8
10.2.129.69:10.0.0.0/8,10.2.128.0/22
10.2.129.70:10.0.0.0/8
10.2.129.70:10.0.0.0/8,10.2.128.0/22
10.2.129.71:10.0.0.0/8
10.2.129.71:10.0.0.0/8,10.2.128.0/22
10.2.129.72:10.0.0.0/8
10.2.129.72:10.0.0.0/8,10.2.128.0/22
10.2.129.73:10.0.0.0/8
10.2.129.73:10.0.0.0/8,10.2.128.0/22
10.2.129.74:10.0.0.0/8
10.2.129.74:10.0.0.0/8,10.2.128.0/22
10.2.129.75:10.0.0.0/8
10.2.129.75:10.0.0.0/8,10.2.128.0/22
10.2.129.76:10.0.0.0/8
10.2.129.76:10.0.0.0/8,10.2.128.0/22
10.2.129.77:10.0.0.0/8,10.2.128.0/22
10.2.129.78:10.0.0.0/8,10.2.128.0/22
10.2.129.79:10.0.0.0/8,10.2.128.0/22
10.2.129.80:10.0.0.0/8,10.2.128.0/22
10.2.129.81:10.0.0.0/8,10.2.128.0/22
10.2.129.82:10.0.0.0/8,10.2.128.0/22
10.2.129.83:10.0.0.0/8,10.2.128.0/22
10.2.129.84:10.0.0.0/8,10.2.128.0/22
10.2.129.85:10.0.0.0/8,10.2.128.0/22
10.2.129.86:10.0.0.0/8,10.2.128.0/22
10.2.129.87:10.0.0.0/8,10.2.128.0/22
10.2.129.88:10.0.0.0/8,10.2.128.0/22
10.2.129.89:10.0.0.0/8,10.2.128.0/22
10.2.129.90:10.0.0.0/8,10.2.128.0/22
10.2.16.208:10.0.0.0/8
10.2.16.222:10.0.0.0/8
10.3.0.249:10.0.0.0/8
10.3.0.67:10.0.0.0/8
10.3.1.6:10.0.0.0/8
10.3.128.10:10.0.0.0/8
10.3.128.20:10.0.0.0/8
10.3.129.1:10.0.0.0/8
10.3.129.2:10.0.0.0/8
10.3.129.3:10.0.0.0/8
10.3.129.4:10.0.0.0/8
10.3.16.216:10.0.0.0/8
10.3.2.11:10.0.0.0/8
10.3.2.12:10.0.0.0/8
10.3.2.1:10.0.0.0/8
10.3.2.3:10.0.0.0/8
10.3.2.4:10.0.0.0/8
10.3.2.5:10.0.0.0/8
10.3.2.6:10.0.0.0/8
10.3.2.7:10.0.0.0/8
10.3.2.9:10.0.0.0/8
10.3.3.11:10.0.0.0/8
10.3.3.12:10.0.0.0/8
10.3.3.13:10.0.0.0/8
10.3.3.14:10.0.0.0/8
10.3.3.15:10.0.0.0/8
10.3.3.16:10.0.0.0/8
10.3.3.17:10.0.0.0/8
10.3.3.18:10.0.0.0/8
10.3.3.19:10.0.0.0/8
10.3.3.1:10.0.0.0/8
10.3.3.20:10.0.0.0/8
10.3.3.21:10.0.0.0/8
10.3.3.24:10.0.0.0/8
10.3.3.26:10.0.0.0/8
10.3.3.27:10.0.0.0/8
10.3.3.28:10.0.0.0/8
10.3.3.29:10.0.0.0/8
10.3.3.2:10.0.0.0/8
10.3.3.30:10.0.0.0/8
10.3.3.32:10.0.0.0/8
10.3.3.33:10.0.0.0/8
10.3.3.34:10.0.0.0/8
10.3.3.35:10.0.0.0/8
10.3.3.36:10.0.0.0/8
10.3.3.37:10.0.0.0/8
10.3.3.38:10.0.0.0/8
10.3.3.39:10.0.0.0/8
10.3.3.3:10.0.0.0/8
10.3.3.40:10.0.0.0/8
10.3.3.41:10.0.0.0/8
10.3.3.4:10.0.0.0/8
10.3.3.5:10.0.0.0/8
10.3.3.6:10.0.0.0/8
10.3.3.7:10.0.0.0/8
10.3.3.8:10.0.0.0/8
10.4.0.10:10.0.0.0/8
10.4.0.14:10.0.0.0/8
10.4.0.6:10.0.0.0/8
linux nfs
Martin Hope
Kamil Kisiel
Asked: 2010-01-29 11:30:52 +0800 CST
  • 4

我有一些带有基于 LSI Logic MPT 芯片（特别是 SAS1068E）的 RAID 阵列的服务器。目前，我知道获取磁盘状态的唯一方法是使用该lsiutil程序并以交互方式查看那里的状态。

我希望能够通过 cron 作业或其他脚本对此进行监控，但lsiutil. 人们用什么？

linux monitoring lsi
Martin Hope
Kamil Kisiel
Asked: 2010-01-16 10:29:50 +0800 CST
  • 0

我们有一些 Windows 用户在家中通过 VPN 连接到我们的网络。他们需要能够连接到我们的 Samba 服务器并访问映射的网络驱动器，就像他们在我们的 LAN 上一样。

复杂之处在于 VPN 客户端被放置在我们办公室 LAN 以外的子网上，并且位于防火墙后面。让他们仍然连接到网络共享的最简单方法是什么？

我目前看到的解决方案包括为名称解析目的设置 WINS 服务器，然后通过防火墙将一堆 NetBIOS 内容隧道化。然而，这意味着我必须设置 VPN DHCP 服务器来分发 WINS 地址，我什至不确定在我们拥有的 Cisco 硬件上是否可行。我想必须有一个更简单的方法。我应该使用 LMHOSTS 文件吗？还是仅按 IP 地址映射？

另外，我对 Windows 网络不是很熟悉，那么我需要通过哪些端口才能通过防火墙进行文件共享？

windows vpn samba
Martin Hope
Kamil Kisiel
Asked: 2009-10-24 09:36:56 +0800 CST
  • 0

我想开始跟踪哪些二进制文件用户在我们的 Linux 集群上运行。我想在每个节点上记录结果，然后汇总它们以找到总数。我希望最终能够在月底运行报告并看到/usr/bin/foo运行了 9000 次。

我的问题是关于日志方面的。什么设施最适合实现这一目标？流程会计？auditd?

具体来说，我希望日志跟踪每个可执行文件运行的路径，以及执行的频率。

linux
Martin Hope
Kamil Kisiel
Asked: 2009-10-08 10:26:16 +0800 CST
  • 6

我有一堆通过 Open-iSCSI 安装在 Dom0 主机中的 iSCSI LUN 运行 Xen VM 的 VM 服务器。这只是一个简单的单路径设置（通过集群存储和虚拟 IP 在目标端实现冗余）

我正在考虑将 Open-iSCSI README 中的设置用于 iSCSI 根目录，因为基本上就是这样：

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try
to re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want theopposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0 
node.conn[0].timeo.noop_out_timeout= 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

我应该考虑在 iSCSI LUN 上以 root 运行 VM 的其他推荐设置吗？

linux
Martin Hope
Kamil Kisiel
Asked: 2009-08-21 13:09:50 +0800 CST
  • 8

这台机器有大量的交换，但进程仍然偶尔会被 oom-killer 杀死。谁能解释这种行为，更重要的是如何防止它发生？

Dmesg 输出：

python invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=4
Pid: 13996, comm: python Not tainted 2.6.27-gentoo-r8cluster-e1000 #9

Call Trace:
 [<ffffffff8025ab6b>] oom_kill_process+0x57/0x1dc
 [<ffffffff802460c7>] getnstimeofday+0x53/0xb3
 [<ffffffff8025ae78>] badness+0x16a/0x1a9
 [<ffffffff8025b0a9>] out_of_memory+0x1f2/0x25c
 [<ffffffff8025e181>] __alloc_pages_internal+0x30f/0x3b2
 [<ffffffff8026fea0>] read_swap_cache_async+0x48/0xc0
 [<ffffffff8026ff6f>] swapin_readahead+0x57/0x98
 [<ffffffff80266d0e>] handle_mm_fault+0x408/0x706
 [<ffffffff8057da33>] do_page_fault+0x42c/0x7e7
 [<ffffffff8057baf9>] error_exit+0x0/0x51

Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
CPU    2: hi:    0, btch:   1 usd:   0
CPU    3: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd: 103
CPU    1: hi:  186, btch:  31 usd:  48
CPU    2: hi:  186, btch:  31 usd: 136
CPU    3: hi:  186, btch:  31 usd: 183
Active:480346 inactive:483 dirty:0 writeback:10 unstable:0
 free:3408 slab:5146 mapped:1408 pagetables:2687 bounce:0
Node 0 DMA free:8024kB min:20kB low:24kB high:28kB active:1156kB inactive:0kB present:8364kB pages_scanned:3246 all_unreclaimable? yes
lowmem_reserve[]: 0 2003 2003 2003
Node 0 DMA32 free:5608kB min:5716kB low:7144kB high:8572kB active:1920228kB inactive:1932kB present:2051308kB pages_scanned:2941301 all_unreclaimable? yes
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 8*4kB 3*8kB 4*16kB 3*32kB 4*64kB 3*128kB 2*256kB 3*512kB 3*1024kB 1*2048kB 0*4096kB = 8024kB
Node 0 DMA32: 42*4kB 6*8kB 1*16kB 0*32kB 2*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 1*4096kB = 5608kB
325424 total pagecache pages
323900 pages in swap cache
Swap cache stats: add 20776604, delete 20452704, find 7856195/10744535
Free swap  = 151691424kB
Total swap = 156290896kB
524032 pages RAM
9003 pages reserved
331431 pages shared
186210 pages non-shared
Out of memory: kill process 12965 (bash) score 2236480 or a child
Killed process 13996 (python)

虚拟机相关的 sysctl：

vm.overcommit_memory = 0
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.oom_dump_tasks = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 2
vm.swappiness = 60
vm.nr_hugepages = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
vm.lowmem_reserve_ratio = 256   256 32
vm.drop_caches = 0
vm.min_free_kbytes = 5740
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65536
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.zone_reclaim_mode = 0
vm.min_unmapped_ratio = 1
vm.min_slab_ratio = 5
vm.stat_interval = 1
vm.numa_zonelist_order = default
linux
Martin Hope
Kamil Kisiel
Asked: 2009-08-19 12:14:11 +0800 CST
  • 2

任何管理 openSUSE 机器网络的人的问题。您如何跟踪和应用更新？我知道 YaST 在线更新 (YOU)，但它似乎更倾向于使单台机器保持最新状态。它似乎不能很好地扩展到大量机器。你如何保持你的机器更新？我们的网络在包安装方面是相当异构的，因为服务器主要是具有不同角色的基础设施机器。

我知道 SUSE Linux Enterprise 有工具来管理网络范围内的更新，但出于预算原因，目前还不能选择更新。

package-management
Martin Hope
Kamil Kisiel
Asked: 2009-07-31 14:18:27 +0800 CST
  • 63

在 Linux 中，如果您经常深入研究，/proc/<pid>/fd您会看到如下输出：

lrwx------ 1 root root 64 Jul 30 15:14 0 -> /dev/null
lrwx------ 1 root root 64 Jul 30 15:14 1 -> /dev/null
l-wx------ 1 root root 64 Jul 30 15:14 10 -> pipe:[90222668]
lr-x------ 1 root root 64 Jul 30 15:14 11 -> pipe:[90222669]
l-wx------ 1 root root 64 Jul 30 15:14 13 -> pipe:[90225058]
lr-x------ 1 root root 64 Jul 30 15:14 14 -> pipe:[90225059]

如何获取有关开放管道的更多信息，例如另一端是哪个进程？

linux pipe
Martin Hope
Kamil Kisiel
Asked: 2009-07-15 13:17:46 +0800 CST
  • 0

我正在尝试为一小部分主机设置基于主机的身份验证。我想我已经把所有的鸭子都排成一排了：

  • 将公钥复制到/etc/ssh/ssh_known_hosts文件中
  • 将所有主机放入/etc/shosts.equiv
  • HostbasedAuthentication在/etc/ssh/sshd_config和中启用/etc/ssh/ssh_config
  • Setuid/usr/lib64/ssh/ssh-keysign二进制文件并在客户端上EnableSSHKeysign yes的文件中设置。/etc/ssh/ssh_config

但是，它仍然不起作用。在调试模式下运行服务器，我得到以下输出：

debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug3: Trying to reverse map address 10.3.128.10.
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 7
debug3: mm_request_receive entering
debug2: parse_server_config: config reprocess config len 137
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug2: input_userauth_request: setting up authctxt for kamil
debug3: mm_start_pam entering
debug3: mm_request_send entering: type 45
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug2: input_userauth_request: try method none
debug3: monitor_read: checking request 45
debug1: PAM: initializing for "kamil"
debug1: PAM: setting PAM_RHOST to "foo.bar.com"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: monitor_read: 45 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug1: userauth-request for user kamil service ssh-connection method hostbased
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method hostbased
debug1: userauth_hostbased: cuser kamil chost foo.bar.com. pkalg ssh-dss slen 55
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x58c400
debug2: userauth_hostbased: chost foo.bar.com. resolvedname foo.bar.com ipaddr 10.3.128.10
debug2: stripping trailing dot from chost foo.bar.com.
debug2: auth_rhosts2: clientuser kamil hostname foo.bar.com ipaddr 10.3.128.10
debug1: temporarily_use_uid: 1031/1028 (e=0/0)
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1031/1028 (e=0/0)
debug1: restore_uid: 0/0
Failed hostbased for kamil from 10.3.128.10 port 55105 ssh2
debug3: mm_answer_keyallowed: key 0x58c400 is disallowed
debug3: mm_request_send entering: type 21
debug3: mm_request_receive entering
debug2: userauth_hostbased: authenticated 0
debug1: userauth-request for user kamil service ssh-connection method hostbased
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method hostbased
debug1: userauth_hostbased: cuser kamil chost foo.bar.com. pkalg ssh-rsa slen 143
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x58c400
debug2: userauth_hostbased: chost foo.bar.com. resolvedname foo.bar.com ipaddr 10.3.128.10
debug2: stripping trailing dot from chost foo.bar.com.
debug2: auth_rhosts2: clientuser kamil hostname foo.bar.com ipaddr 10.3.128.10
debug1: temporarily_use_uid: 1031/1028 (e=0/0)
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1031/1028 (e=0/0)
debug1: restore_uid: 0/0
Failed hostbased for kamil from 10.3.128.10 port 55105 ssh2
debug3: mm_answer_keyallowed: key 0x58c400 is disallowed
debug3: mm_request_send entering: type 21
debug3: mm_request_receive entering
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug2: userauth_hostbased: authenticated 0
debug1: userauth-request for user kamil service ssh-connection method keyboard-interactive
debug1: attempt 3 failures 3
debug2: input_userauth_request: try method keyboard-interactive

问题的症结似乎在于：

debug3: mm_answer_keyallowed: key 0x58c400 is disallowed

想法？

linux ssh
Martin Hope
Kamil Kisiel
Asked: 2009-07-10 22:48:41 +0800 CST
  • 6

我想将所有 ZFS ACL 从一个文件克隆到另一个文件。

使用 POSIX ACL，这可以通过管道输出getfaclto 来完成setfacl。

ZFS 中的 NFSv4 样式 ACL 是否有一种简单快捷的方法来执行此操作？我知道我可以读取 的输出，ls -lV然后将其作为 a 的一部分输入chmod，但我似乎找不到与复制 ACL 的 POSIX 方式等效的功能。

solaris access-control-list zfs
Martin Hope
Kamil Kisiel
Asked: 2009-07-10 19:33:37 +0800 CST
  • 23

我想对我们的 NFS 服务器进行一些分析，以帮助追踪我们应用程序中的潜在瓶颈。服务器正在运行 SUSE Enterprise Linux 10。

我想知道的事情是：

  • 哪些客户端正在访问哪些文件
  • 每个客户端的读/写吞吐量
  • 其他 RPC 调用带来的开销
  • 等待其他 NFS 请求或磁盘 I/O 以服务客户端所花费的时间

我已经知道可用的统计数据/proc/net/rpc/nfsd，事实上我写了一篇博客文章深入描述了它们。我正在寻找的是一种更深入地挖掘并帮助了解哪些因素会影响特定客户所看到的性能的方法。我想分析 NFS 服务器在我们集群上的应用程序性能中所起的作用，以便我能想出最佳优化它的方法。

performance linux nfs
Martin Hope
Kamil Kisiel
Asked: 2009-07-03 15:39:31 +0800 CST
  • 12

我一直在考虑mod_auth_kerb在我们的内部 Web 服务器上部署以启用 SSO。我可以看到的一个明显问题是，这是一种全有或全无的方法，您的所有域用户都可以访问一个站点，也可以不访问。

是否可以结合检查mod_auth_kerbLDAPmod_authnz_ldap中特定组的组成员资格？我猜这个KrbAuthoritative选项会与此有关吗？

另外，据我了解，该模块将用户名设置为username@REALM身份验证后，但当然在目录中用户仅存储为用户名。此外，我们运行的一些内部站点（例如 trac）已经有一个与每个用户名相关联的用户配置文件。有没有办法解决这个问题，也许是在身份验证后以某种方式剥离领域位？

apache-2.2 ldap kerberos single-sign-on
Martin Hope
Kamil Kisiel
Asked: 2009-06-26 09:49:17 +0800 CST
  • 5

我想知道这是否可能。我希望用户能够在我们的一些主机上启动屏幕，以便多路复用他们的终端登录会话。但是，我不希望他们能够分离屏幕并让它在后台运行。

这样做的原因是登录到这些机器的唯一方法是通过集群作业提交系统，所以如果屏幕分离并且用户注销，唯一的返回方法是如果他们碰巧重新登陆下一个作业提交的相同节点。

gnu-screen
Martin Hope
Kamil Kisiel
Asked: 2009-06-25 20:40:55 +0800 CST
  • 0

我正在尝试设置一个 CIFS 共享，它将自动安装在我的 OpenSolaris 服务器上。看起来它很简单，但是我的语法有问题阻止它安装。

/etc/vfstab 中的行如下所示：

//user:[email protected]/data      -       /mount_point   smbfs   -       yes     -

但是，当我尝试使用它安装它时，mount /mount_point我收到一条错误消息：

mount: Mount point cannot be determined

我已经搜索了手册页和网络，但我看不出我做错了什么。

编辑：我确实启动了 svc:/network/smb/client 服务，并且可以使用手动挂载卷mount -F smbfs ....，但到目前为止，vfstab 或 autofs 都没有运气。

cifs opensolaris
Martin Hope
Kamil Kisiel
Asked: 2009-06-24 14:41:34 +0800 CST
  • 9

我的 Xen 服务器是 openSUSE 11.1，带有 open-iscsi 到我们的 iSCSI SAN 集群。SAN 模块位于启动器连接到的虚拟 IP 后面的 IP 故障转移组中。

如果主 SAN 服务器出现故障，则辅助 SAN 服务器将扮演目标角色。这一切都由 LeftHand SAN/iQ 软件处理，并且在大多数情况下都能正常工作。

我遇到的问题是，有时我的一些 Xen DomU 在 IP 故障转移后会使其根文件系统变为只读。它并不一致，并且每次发生故障转移时都会发生在不同的子集上。它们都运行相同的 openSUSE 11.1 软件映像。

每个 DomU 的根文件系统由 Dom0 中的 open-iscsi 挂载，然后 Xen 使用标准块设备驱动程序将其公开给 DomU。

确切的症状是作为 root 运行touch /test返回错误“只读文件系统”。但是， 的输出mount显示它正在以读写方式安装。当然，此时 domU 上的所有其他 I/O 也出现故障，因此机器严重停机。只需xm从 Dom0 重新启动它，甚至无需重新连接 iSCSI 会话，就可以让一切恢复正常。

在 Dom0 端，故障转移期间的 syslog 消息类似于以下内容：

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts)

我很难弄清楚在哪一层调试这个问题，它是 DomU 内核中的东西吗？还是在 Dom0 或 Xen 级别？我认为某处可能有一些参数需要调整以增加某种超时，但我不确定在哪里看。

我真的不认为 open-iscsi 有问题，因为连接的块设备仍然可以从 Dom0 读取和写入。

xen linux iscsi
Martin Hope
Kamil Kisiel
Asked: 2009-06-12 13:38:00 +0800 CST
  • 4

这是一个我无法诊断的问题：

我们的用户主目录通过 NFS 从运行 Mac OS X 10.5.7 的 Apple XServe 提供。通常它们被导出到我们的默认办公室子网“lan”。最近我一直在构建一个新的子网，“农场”。“农场”上的计算机与“局域网”上的计算机运行相同的操作系统（openSUSE 11.1 和 Gentoo），并且软件版本相同。

问题是，当我的用户在“农场”上使用机器一段时间（5 分钟，有时 30 分钟，有时一小时）时，NFS 挂载似乎只是挂起。尝试对ls目录或尝试访问用户主目录的任何其他操作（例如登录等）进行操作只会卡住。从“挂起”的机器挂载到其他 NFS 服务器似乎按预期工作。

客户端或服务器的日志中没有任何内容表明有任何问题。相同类型的客户端可以在默认的“lan”子网中正常工作。

我尝试了 NFS 服务器和客户端的各种不同配置（禁用/启用 kerberos，不同的挂载选项），但似乎没有任何区别。

我强烈怀疑这两个子网之间存在一些网络级别的问题，可能是防火墙/路由器（OpenBSD 使用 pf 作为数据包过滤器）造成的一些问题。两组机器之间的连接相当简单： x serve --> switch --> router --> switch --> clients

对于接下来要尝试的调试方法，或者可能的解决方案可能是什么，我几乎一无所知。关于如何从这一点上解决这个问题的任何想法？

更新：

仍然无法解决这个问题。当我在内部接口上禁用时，我以为我已经将它扼杀在萌芽状态scrub，但问题再次显现出来。奇怪的是 pf 似乎还在修改一些数据包。

在农场vlan 端的示例对话：

09:17:39.165860 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF)
09:17:39.166124 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 43 win 65535 <nop,nop,timestamp 316702204 236992843> (DF)
09:17:54.164490 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.164760 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1441270809:1441270809(0) ack 43 win 65535 (DF)
09:17:54.164776 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 4243886205:4243886205(0) ack 46 win 0 (DF)
09:17:54.164989 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:57.164066 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF)
09:17:57.164330 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702384 236997343> (DF)
09:18:03.163468 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF)
09:18:03.163732 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)

在lan vlan 上也是如此：

09:17:39.165876 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF)
09:17:39.166110 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702204 236992843> (DF)
09:17:54.164505 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.164740 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1:1(0) ack 1 win 65535 (DF)
09:17:54.164745 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 2802615397:2802615397(0) ack 4 win 0 (DF)
09:17:54.165003 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.165239 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702354 236996593,sackOK,eol> (DF)
09:17:55.123665 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702363 236996593,sackOK,eol> (DF)
09:17:57.124839 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702383 236996593,sackOK,eol> (DF)
09:17:57.164082 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF)
09:17:57.164316 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702384 236997343> (DF)
09:18:01.126690 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702423 236997343,sackOK,eol> (DF)
09:18:03.163483 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF)
09:18:03.163717 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)

我还应该提到，我们有其他 NFS 流量通过同一台机器，但来自不同的 NFS 服务器。我们多年来一直在使用它，并且在那里没有遇到任何问题。同样，这些 XServes 也已经在自己的子网上为 Linux 客户端提供 NFS 服务很长时间了，并且会继续这样做。

linux nfs mac-osx openbsd pf
Martin Hope
Kamil Kisiel
Asked: 2009-06-11 12:28:56 +0800 CST
  • 1

我们有一个基于 OSX 的网络，包括使用 OpenDirectory 作为我们的目录服务。我们的网络由一个 OD 主节点和一对 OD 副本组成。我们一直在尝试对其进行设置，以便当主服务器出现故障时，工作站将针对其中一个副本进行身份验证。但是，尽管主服务器已关闭，但客户端似乎继续尝试访问主服务器。这应该“正常工作”，但它似乎不适合我们。有人建议我们需要手动将副本提升为 master 以便让客户端进行故障转移，但这似乎有些荒谬。

有没有人使这个配置工作？似乎没有很多关于细节的文档。

mac-osx opendirectory
Martin Hope
Kamil Kisiel
Asked: 2009-06-08 21:12:01 +0800 CST
  • 3

我们在办公室有一个小型 Xen 服务器集群。每个虚拟机系统映像都位于 iSCSI SAN 上自己的块设备上。这些服务器都同时将它们的 iSCSI 启动器连接到每个 VM LUN。

为了防止同一个虚拟机在多个主机上启动，我们只需确保每个虚拟机仅通过使用xm new. virt-manager通过帮助对所有服务器进行明智的监控。但是，确实没有任何安全措施可以防止某人在多个主机上意外启动同一个虚拟机。

我的问题是，为这样的设置实施更好的管理系统的好方法是什么？是否有任何现有的工具可以通过共享存储后端管理这样的 Xen 设置？

我们使用 openSUSE 11.1 作为主机操作系统。

xen storage-area-network iscsi