Janus服务器《三》--Admin/Monitor API

Janus Admin API 是用于查询和管理会话、句柄及服务器配置的接口。它提供同步机制,包括获取服务器信息、配置变量、会话管理、句柄操作等功能。启用此API需要在配置文件中设置,并通过特定的请求路径和JSON消息进行交互。例如,可以使用它来获取会话列表、改变日志级别或抓包WebRTC媒体流。此外,Admin API还支持事件句柄管理和自定义日志记录。

1、Admin/Monitor API

  用于向janus服务器查询一些和会话及句柄有关的信息,在查找媒体流层面问题时显得非常有用。目前Admin API只能用于信息查询不能与janus进行更多的交互(如强制删除会话),更多的交互还是得使用RESTful、Websockets等transport模块的API。该API只提供同步机制,如果你需要的是异步通知机制的话请使用janus的event handler。默认的根请求路径为/admin
在这里插入图片描述

  该API接口默认是关闭的,你可以在相应的传输方式的配置文件中将其开启。例如在janus.transport.http.jcfg文件编辑admin部分。
在这里插入图片描述

  该API接口的消息格式和transport API的非常相似,因此这篇文档只简略的提到不同之处。当你是用websockets方式时需要将“janus-admin-protocol”作为子协议替换janus API中的"janus-protocol"。
在这里插入图片描述

2、Admin API请求

2.1、通用请求

  • info : 请求janus服务器的信息,和janus 的info API返回的结果一致,不需要秘钥即可请求;
  • ping :一个简单的ping/pong机制,客户端可用该接口来链路检查及预测协议的路由时间,也是不需要秘钥即可请求;

2.2、配置相关请求

  • get_status: 返回当前服务器能被Admin API动态修改的配置变量;
  • set_session_timeout: 改变全局的会话超时时间;
  • set_log_level: 改变日志等级;
  • set_log_timestamps:使能或禁止在日志中添加时间戳;
  • set_log_colors: 使能或禁止日志带颜色输出;
  • set_locking_debug: 使能或禁止锁(互斥锁等)的实时调试,在遇到死锁时很有用;
  • set_refcount_debug:使能或禁止引用计数的实时调试,在遇到janus内部结构体内存泄漏时使用;
  • set_libnice_debug:使能或禁止libnice库的调试;
  • set_min_nack_queue:改变NACK队列的最小值;
  • set_no_media_timer: 改变没有媒体流的计时器值;
  • set_slowlink_threshold: 改变线路质量阈值;
    在这里插入图片描述

2.3、Token相关的请求

这部分请求只有在使能了token存储的机制之后才有效

  • add_token: 增加一个有效tocken
  • allow_token: 给与一个与插件使用相关的token;
  • disallow_token:移除一个与插件使用有关的token;
  • list_tokens: 列出现存的所有token;
  • remove_token:删除一个token
    在这里插入图片描述

2.4、会话相关的请求

  • accept_new_sessions: 配置janus是否应该接受一个新的会话(当你任何时候想要清空一个janus实例使用这个非常方便—感觉很别扭)
  • list_sessions:列出现存的active状态的会话;
  • set_session_timeout: 改变会话超时时间;
  • destory_session: 销毁一个会话;
    在这里插入图片描述

2.5、句柄及webrtc相关的请求

  • list_handles: 列出现存的active状态的ICE句柄;
  • handle_info: 列出特定ICE句柄的所有信息。如果将plugin_only变量值设置为true则仅返回插件相关的信息,webrtc信息及状态均不会被包含在返回信息中。
  • start_pcap: 开始将发送的RTP/RTCP包抓包保存成pcap文件;
  • stop_pcap:停止抓包
  • start_text2pcap:和start_pcap请求一样,但是保存为text文件
  • stop_text2pcap:停止text2pcap抓包
  • message_plugin:发送同步消息给插件。几乎所有插件都实现该请求用于优化该插件的资源管理。
  • handup_webrtc: 挂断特定ICE句柄的PeerConnection;
  • detach_handle:分离特定的句柄,和janus API的detach消息的功能一致;
    在这里插入图片描述

2.6、事件句柄相关请求

  • query_eventhandler: 发送一个同步请求给一个事件句柄;
  • custom_event: 通过事件句柄发布一个自定义的外部事件。当第三方应用需要以简单的方式和janus内部产生的事件相关联时或者推送janus无法获得的信息时使用该接口。
    在这里插入图片描述

2.7、自定义log信息请求

  • custom_logline: 将第三方应用的log信息添加到janus的log输出或文件中。log等级可选。
    在这里插入图片描述

2.8、工具类请求

  • resolve_address: 用于判断janus是否可找到一个网址的DNS及对应的查询耗时。
  • test_stun: 用于判断janus可否能连接上STUN服务器,获得从STUN服务器的响应信息及响应耗时。
    在这里插入图片描述

3、Admin API语法规则

  Admin API和Janus API所遵循的规则是一样的,即请求正确的路径或在请求正确路径时携带正确的session_id和handle_id。
  《1》、全局请求 全局请求无需session_id和handle_id。包括2.1的通用请求,2.2的配置请求,2.3的Token请求,2.6的事件相关请求,2.8的工具类请求及accept_new_session、list_sessions请求。
例子:

POST /admin

{        
     "janus" : "list_sessions",        
     "transaction" : "<random alphanumeric string>",        
     "admin_secret" : "<password specified in janus.jcfg, if any>"
}

  《2》、仅需要session_id的请求
   如destory_session、list_handles。注意所以REST接口直接在POST的url中添加session_id就能实现这些请求,但是更通用的(适用于所有协议的)方法是在json消息中添加session_id字段。
例子:

POST /admin/12345678
{        
    "janus" : "list_handles",       
    "session_id" : 12345678,       
    "transaction" : "<random alphanumeric string>",       
    "admin_secret" : "<password specified in janus.jcfg, if any>"
} 

  《3》、需要session_id及handle_id的请求
  这些请求包括handle_info,所有和抓包有关的请求、message_plugin、hangup_webrtc和detach_handle。
例子:

POST /admin/12345678/98765432
{        
       "janus" : "handle_info",        
       "session_id" : 12345678,        
       "handle_id" : 98765432,
        "transaction" : "<random alphanumeric string>",
        "admin_secret" : "<password specified in janus.jcfg, if any>"
}

4、抓包未加密的WebRTC媒体流

  你可以开启或禁止抓包一个handle发送和接收的RTP及RTCP包。这个功能在调试时会显得非常有用。需要注意的是如果要进行录制最好使用janus_recorder工具而不是开启抓包(它能实现录制)。
例子:

开始抓包

POST /admin/12345678/98765432
{        
      "janus" : "start_pcap",         // Use start_text2pcap for a text file instead       
      "folder" : "<folder to save the dump to; optional, current folder if missing>",        
      "filename" : "<filename of the dump; optional, random filename if missing>",        
      "truncate" : "<number of bytes to truncate packet at; optional, truncate=0 (don't truncate) if missing>",        
      "transaction" : "<random alphanumeric string>",       
      "admin_secret" : "<password specified in janus.jcfg, if any>"
}


停止抓包

POST /admin/12345678/98765432
{        
   "janus" : "stop_pcap",          // Use stop_text2pcap if you started a text-based capture        
   "transaction" : "<random alphanumeric string>",        
   "admin_secret" : "<password specified in janus.jcfg, if any>"
}

5、参考

《1》Admin/Monitor API

<think>我们之前讨论过Cassandra在Podman中运行的权限问题,现在用户遇到了具体的权限拒绝错误:错误信息:`/opt/cassandra/bin/cassandra:206: exec: :Permission denied`用户使用root执行,但容器内部仍然出现权限拒绝。这通常与容器内的文件权限或SELinux有关。分析:1.用户使用了两个卷挂载:-`-v /opt/janusgraph/conf/cassandra:/etc/cassandra:Z`- `-v/home/iaas/janusgraph-full-0.6.3/cassandra/lib:/usr/share/cassandra/lib:Z`注意:这两个挂载都使用了`:Z`选项,这表示Podman会重新标记卷以符合SELinux策略(如果启用了SELinux)。2.错误发生在执行Cassandra的启动脚本时,具体是第206行,提示权限拒绝。可能的原因: a)挂载的宿主机目录中的文件权限在容器内不可执行(尽管宿主机是root,但容器内用户可能没有权限)。b)SELinux阻止了访问。解决步骤:步骤1:检查挂载目录的权限确保宿主机上挂载的目录和文件对容器内的用户可读(配置文件)和可执行(如果有脚本)。Cassandra容器默认使用用户`cassandra`(UID=999)运行。检查宿主机目录的权限:-`/opt/janusgraph/conf/cassandra`和`/home/iaas/janusgraph-full-0.6.3/cassandra/lib`-确保这些目录对用户999(或至少其他用户可读)有读权限。如果是配置文件,通常需要读权限;如果是lib目录,需要读和执行权限(因为JAR文件需要读取)。例如,可以运行:```bashls -ld /opt/janusgraph/conf/cassandrals-l/opt/janusgraph/conf/cassandrals -ld /home/iaas/janusgraph-full-0.6.3/cassandra/libls -l /home/iaas/janusgraph-full-0.6.3/cassandra/lib```步骤2:临时关闭SELinux进行测试(如果启用了SELinux)为了确定是否是SELinux导致的问题,可以临时禁用SELinux:```bashsetenforce0```然后重新运行容器。如果问题解决,则说明是SELinux的问题。步骤3:正确使用SELinux标签如果步骤2中确定是SELinux的问题,那么需要确保正确标记卷。用户已经使用了`:Z`选项,这应该会为卷设置正确的标签。但是,如果宿主机目录原本的SELinux上下文不正确,可能需要调整。也可以尝试使用`:z`(小写)替代`:Z`,这会将卷的标签设置为共享,这样多个容器都可以访问。但注意:`:Z`是私有非共享的,而`:z`是共享的。不过,根据Podman文档,对于单个容器使用的卷,`:Z`是合适的。步骤4:检查容器内文件的权限如果上述步骤不能解决,可以进入容器检查文件权限:```bashpodman exec-itcassandra/bin/bash```然后检查:- `/etc/cassandra`目录下的文件权限- `/usr/share/cassandra/lib`目录下的文件权限特别是,注意启动脚本`/opt/cassandra/bin/cassandra`(在容器内)是否可执行?以及它依赖的文件是否可读?步骤5:调整宿主机目录权限如果发现容器内用户(cassandra,UID=999)没有访问挂载目录的权限,可以尝试在宿主机上修改目录权限:```bashchmod-Ro+rx /opt/janusgraph/conf/cassandrachmod -R o+rx/home/iaas/janusgraph-full-0.6.3/cassandra/lib```注意:`o+rx`给其他用户读和执行权限。但要注意安全性。或者,更安全的方法是更改目录的所有者为UID=999(但需要确保宿主机的这个UID存在,通常不存在,所以我们可以使用`chown`到某个已知用户,然后在挂载时使用`--user`指定用户,但这里我们使用卷的SELinux标签可能更合适)。步骤6:使用`--user`选项指定容器内用户如果宿主机目录的所有者是root,我们可以尝试在运行容器时指定root用户(但Cassandra官方镜像不建议以root运行):```bashpodmanrun -d ...--userroot ...docker.io/library/cassandra:4.0```但这不是推荐的做法,因为Cassandra通常以非root用户运行。然而,如果只是为了测试,可以尝试。如果以root运行成功,则说明是权限问题,需要调整挂载目录的权限。步骤7:检查挂载的配置文件内容另外,注意错误信息中提到的行号(206行)。查看Cassandra启动脚本的第206行是什么?可能是某个命令无法执行。这可能是由于挂载的配置文件中的某些设置导致。由于用户挂载了自定义配置目录(`/opt/janusgraph/conf/cassandra`),这个目录下的文件可能会覆盖容器内的配置文件。检查这些文件,特别是脚本文件(如果有)是否具有可执行权限?或者是否有错误的配置?实际解决方案:根据经验,最常见的原因是SELinux。因此,我们可以建议:1.确保宿主机目录的SELinux上下文正确。使用`:Z`选项后,Podman会重新标记,但有时可能需要手动修复。2.或者,如果宿主机启用了SELinux,并且用户希望保持SELinux开启,那么可以尝试在运行容器之前,手动为宿主机目录添加SELinux上下文:```bashchcon -R system_u:object_r:container_file_t:s0/opt/janusgraph/conf/cassandrachcon-Rsystem_u:object_r:container_file_t:s0 /home/iaas/janusgraph-full-0.6.3/cassandra/lib```然后重新运行容器(不使用`:Z`,因为我们已经手动标记)。但是,使用Podman的卷标志(`:Z`)通常更方便。如果用户不想处理SELinux,可以禁用SELinux(生产环境不推荐)或者设置SELinux为permissive模式。我们给出一个推荐的解决方案:方案一:重新运行容器并确保正确使用卷标签(使用`:Z`),并检查宿主机目录的权限。方案二:如果问题仍然存在,尝试在宿主机上递归更改挂载目录的权限,让其他用户可读可执行(注意安全性):```bashchmod-Ra+rx /opt/janusgraph/conf/cassandrachmod -R a+rx/home/iaas/janusgraph-full-0.6.3/cassandra/lib```方案:如果SELinux是问题根源,且用户不需要SELinux,可以永久禁用(需要重启):修改`/etc/selinux/config`,设置`SELINUX=disabled`,然后重启。但是,生产环境建议使用SELinux,因此更推荐使用正确的标签。另外,注意错误信息中提到的具体行号(206行)可能指向具体的命令。我们可以查看容器内的启动脚本的第206行是什么?由于用户使用的是Cassandra4.0镜像,我们可以查看该镜像的启动脚本(在容器内路径为`/opt/cassandra/bin/cassandra`)的第206行。根据Cassandra4.0的Dockerfile,启动脚本是`bin/cassandra`。第206行可能是执行某个命令,比如`exec`。可能是脚本中尝试执行某个文件,但该文件没有执行权限。因此,重点检查挂载的卷中是否包含需要执行的文件?例如,用户挂载的`/usr/share/cassandra/lib`目录,这个目录通常是JAR文件,不需要执行权限。而配置文件目录`/etc/cassandra`通常也不包含可执行文件。所以,可能是启动脚本本身被覆盖了?用户挂载了`/etc/cassandra`,而Cassandra的启动脚本在`/opt/cassandra/bin`下,不会覆盖。但是,配置文件目录中是否有脚本?一般没有。因此,更可能是SELinux导致的问题。我们给出具体的解决步骤:1.检查SELinux状态:```bashgetenforce```如果返回Enforcing,则进入下一步。2.尝试在Permissive模式下运行:```bashsudo setenforce0```然后重新运行容器。如果问题消失,则确认是SELinux问题。3.永久解决方案(在SELinux开启的情况下):-使用`:Z`标志,Podman会自动设置正确的标签。-如果仍然不行,尝试在宿主机上手动修改标签:```bashsudochcon -R system_u:object_r:container_file_t:s0/opt/janusgraph/conf/cassandrasudo chcon -R system_u:object_r:container_file_t:s0/home/iaas/janusgraph-full-0.6.3/cassandra/lib```然后重新运行容器(去掉`:Z`标志,因为已经手动标记)。4.如果用户希望使用`:Z`标志,也可以尝试先删除挂载目录的SELinux标签,然后让Podman重新标记:```bashsudo restorecon -Rv /opt/janusgraph/conf/cassandrasudorestorecon-Rv/home/iaas/janusgraph-full-0.6.3/cassandra/lib```然后运行容器时使用`:Z`。5.如果上述方法都不行,考虑将整个目录复制到另一个位置(比如`/tmp`下),然后挂载这个新目录(使用`:Z`),以排除原有目录的特殊属性。另外,注意:用户挂载的目录中可能包含隐藏文件(如`.gitkeep`)导致权限问题?确保所有文件都是Cassandra需要的,并且有正确的权限。最后,如果用户不需要自定义配置,可以先不使用挂载卷,测试容器能否正常运行。如果可以,再逐步添加挂载卷以定位问题。由于用户的问题描述中错误信息很短,我们可能需要更多的日志。建议用户查看完整的容器日志:```bashpodmanlogs cassandra```根据以上分析,我们给出一个综合性的解决方案。</think>### 解决 Podman 运行 Cassandra 容器的权限拒绝问题 #### 问题分析 根据错误信息 `/opt/cassandra/bin/cassandra: 206: exec: : Permission denied`,核心问题在于容器内文件系统的权限配置。常见原因包括: 1. **SELinux 限制**:默认安全策略阻止容器访问宿主机文件系统[^1] 2. **挂载目录权限**:宿主机目录权限不足,导致容器内用户无法执行文件 3. **卷挂载标签**:缺少正确的 SELinux 标签(:Z/:z) 4. **文件所有权冲突**:容器用户(UID 999)无法访问宿主机文件 --- #### 解决方案步骤 ##### 1. 检查并调整 SELinux 策略 ```bash # 临时禁用 SELinux (测试用) sudo setenforce 0 # 永久解决方案:添加 SELinux 策略 sudo semanage fcontext -a -t container_file_t "/opt/janusgraph/conf/cassandra(/.*)?" sudo semanage fcontext -a -t container_file_t "/home/iaas/janusgraph-full-0.6.3/cassandra/lib(/.*)?" sudo restorecon -Rv /opt/janusgraph/conf/cassandra sudo restorecon -Rv /home/iaas/janusgraph-full-0.6.3/cassandra/lib ``` ##### 2. 验证挂载目录权限 确保容器用户(cassandra, UID 999)有访问权限: ```bash # 查看目录权限 ls -ld /opt/janusgraph/conf/cassandra ls -ld /home/iaas/janusgraph-full-0.6.3/cassandra/lib # 授予容器用户访问权限 sudo chown -R 999:999 /opt/janusgraph/conf/cassandra sudo chown -R 999:999 /home/iaas/janusgraph-full-0.6.3/cassandra/lib sudo chmod -R 755 /opt/janusgraph/conf/cassandra ``` ##### 3. 修正卷挂载标签 在挂载参数中使用正确的 SELinux 标签: ```diff - -v /opt/janusgraph/conf/cassandra:/etc/cassandra:Z - -v /home/iaas/janusgraph-full-0.6.3/cassandra/lib:/usr/share/cassandra/lib:Z + -v /opt/janusgraph/conf/cassandra:/etc/cassandra:z # 使用共享标签 + -v /home/iaas/janusgraph-full-0.6.3/cassandra/lib:/usr/share/cassandra/lib:z ``` ##### 4. 使用完整启动命令 ```bash podman run -d --name cassandra \ -p 9042:9042 \ -v /opt/janusgraph/conf/cassandra:/etc/cassandra:z \ -v /home/iaas/janusgraph-full-0.6.3/cassandra/lib:/usr/share/cassandra/lib:z \ -e CASSANDRA_CONF=/etc/cassandra \ -e CLASSPATH=/usr/share/cassandra/lib/* \ -e CASSANDRA_USER=cassandra \ # 显式指定用户 docker.io/library/cassandra:4.0 ``` ##### 5. 诊断容器内部权限 ```bash # 进入容器检查文件权限 podman exec -it cassandra bash ls -l /etc/cassandra ls -l /usr/share/cassandra/lib # 检查启动脚本权限 ls -l /opt/cassandra/bin/cassandra ``` --- #### 关键配置说明 1. **:z 与 :Z 的区别**: - `:z`:共享 SELinux 上下文(多容器可访问- `:Z`:私有 SELinux 上下文(仅限单个容器) 2. **用户映射**: Cassandra 镜像默认使用用户 `cassandra` (UID 999),需确保宿主机文件对该用户可读 3. **权限继承**: 挂载目录的权限由宿主机决定,容器内操作受限于宿主机文件系统权限 > **注意**:生产环境中建议使用 `podman unshare` 管理用户命名空间映射,避免直接使用 root 权限[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值