一个伪linux粉丝的blog
  1. 首页
  2. unix/linux
  3. 正文

nexus and squid

2020年04月24日 383点热度 0人点赞 0条评论

记录一次客户nexus仓库拉包失败排错过程,404 images not found起初以为是没搭好nexus仓库,后来查日志404之前有1个403授权错误,抓包才发现403的前面还有1个407授权错误,最终定位是squid代理账号授权问题。

1. 基本信息

1.1. 报错信息

客户测试环境,用户需要通过 nexus 仓库拉外网 openjdk 包,提示镜像文件不存在,后续测试发现任意线上的包都无法拉取。

[[email protected] ~]# docker  pull nexus.smec-cn.com/openjdk-12:alpine
Pulling repository nexus.smec-cn.com/openjdk-12
Error: image openjdk-12:alpine not found

2. 事件影响

客户无法正常使用 nexus 仓库拉取外网包,nexus代理无效

3. 故障解决

3.1. 问题定位

3.1.1. 环境问题

参考交付提供的《Nexus镜像代理外网镜像拉取步骤》 文档,按照说明操作结果无法拉包,后来才知道环境改变了。

后来找到3月最新 《Nexus和SonarQube迁移部署方案 》文档,能够通过 ip 拉到仓库中已有的镜像了,如下 alpine:3.10拉取成功

[[email protected] ~]# docker  pull 10.1.113.217:31180/alpine:3.10
3.10: Pulling from alpine
58abef114fb1: Pull complete
Digest: sha256:9e6ceefe2882de265596f742069f1e18d942f9ac00df2a6f722cc4fafc2a0d4b
Status: Downloaded newer image for 10.1.113.217:31180/alpine:3.10

但是外网镜像其他依然无法拉取,陷入困境。

3.1.2. 新尝试

  • 在公司内网环境,自己 搭建了一个 Nexus 仓库, 参见 → Nexus实践
  • 测试发现外网包能够通过 nexus 仓库拉取,并正常缓存下来。

3.1.3. 继续排查客户环境

  • 更改 nexus 日志级别,org.sonatype.nexus.repository 从 info 设置为 debug

发现如下日志,提示的镜像包不存在,原来首先是403 授权问题,随后才有404,镜像不存在的提示

2020-04-24 06:51:54,877+0000 WARN [qtp1061988004-13854] anonymous org.sonatype.nexus.repository.docker.internal.V2Handlers - Error: GET /v2/library/openjdk-12/manifests/alpine: 403 - org.sonatype.nexus.repository.docker.internal.V2Exception: access to the requested resource is not authorized
2020-04-24 06:51:54,898+0000 WARN [qtp1061988004-40898] *UNKNOWN org.sonatype.nexus.repository.docker.internal.V1Handlers - Error: GET /v1/repositories/openjdk-12/images: 404 - org.sonatype.nexus.repository.docker.internal.V1Exception$ImagesNotFound: images not found
2020-04-24 06:51:54,899+0000 WARN [qtp1061988004-40898] *UNKNOWN org.sonatype.nexus.repository.docker.internal.V1Handlers - Error: GET /v1/repositories/openjdk-12/images: 404 - org.sonatype.nexus.repository.docker.internal.V1Exception$ImagesNotFound: images not found

3.1.4. 抓包

  • 由于还不确定这个 403 到底是哪里给出的,于是开始抓包

3.1.4.1. 抓包步骤

  • 找到nexus部署的节点 10.1.113.217
  • 依次找到 nexus 容器id ffac9a8bc12c,进程pid 32587,发送拉包请求的同时,开始nsenter抓包
1
2
3
4
5
6
[[email protected] ~]# docker ps -a|grep nexus
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ffac9a8bc12c hub-uat.fakename.com/cloud/nexus3:3.18.1 "sh -c ${SONATYPE_DI…" 6 weeks ago Up 6 weeks 0.0.0.0:8081->8081/tcp, 0.0.0.0:31180->31180/tcp nexus
[[email protected] ~]# docker inspect -f{{.State.Pid}} ffac9a8bc12c
32587
[[email protected] ~]# nsenter -t 32587 -n tcpdump -X >nexus.dump-azk8s-http.log

抓包发现407授权问题,这是来自squid 的提示,问题终于找到了。

3.2. 故障根源

  • 用户squid 代理 账号设置问题
  • rfc 文档定义

407 Proxy Authentication Required

  • squid 关于407 部分 描述

How does Proxy Authentication work in Squid?

4. 解决方案

请用户检查 Squid 设置,是否排除了Nexus这里的 basic 授权模式,修改squid.conf配置文件即可。

 

 

5. 后续改进

1,排错时,更改 Nexus 日志级别,org.sonatype.nexus.repository 从 info 设置为 debug

2,排错时考虑 Nexus 所在节点抓包

3,了解 Nexus 仓库拉包全过程

4,了解客户Squid 设置认证方式

流泪更新, tcpdump这边更新,今天抓的包都报错 wireshar “The capture file appears to be damaged or corrupt.
(vwr: Invalid data length 3289632 (runs past the end of the record))” 抓了n次,传了n次。

原来最后 tcpdump -X 之后不能 > 定向输出 abcname,只能 -w abcname

Related posts:

  1. docker-upgrade
  2. Docker "fork/exec /proc/self/exe: no such file or directory\""
  3. Non existing device docker--vg-docker--pool
  4. 服务器日志合并统计实战-squid
标签: nexus squid
最后更新:2020年11月05日

WanJie

正经人谁写博客啊?你写博客吗?写出来的那能叫博客?

点赞
< 上一篇
下一篇 >

文章评论

取消回复

分类目录
  • network
  • Uncategorized
  • unix/linux
  • 业界资讯
  • 公司杂事
  • 数码影像
  • 美剧
  • 美图共赏
  • 英语学习

COPYRIGHT © 2008-2021 一个伪linux粉丝的blog. ALL RIGHTS RESERVED.

THEME KRATOS MADE BY VTROIS