<![CDATA[Heck's Blog]]> https://www.heckjj.com/index.php zh-cn https://www.heckjj.com/post/686/ <![CDATA[Git不同服务器配置不同身份]]> Heck <@hecks.tk> Thu, 21 May 2026 01:48:34 +0000 https://www.heckjj.com/post/686/ [user]
  name = heck
  email = i@heckjj.com

# ======================
# 自动切换 heckjj 账号
# ======================
[includeIf "hasconfig:remote.*.url:https://git.tencent.com/**"]
  path = .gitconfig-tencent

最后一步：必须新建这个文件
打开文件夹：C:\Users\你的用户名\
新建一个文件，名字叫：
.gitconfig-tencent
内容只有这两行：
[user]
  name = heck
  email = heck@tencent.com

这样就自动生效了
所有 git.tencent.com 仓库 → 自动用 heck
其他所有仓库 → 用你的默认账号 heck
不用手动切换，不用每个仓库单独设置
]]> https://www.heckjj.com/post/685/ <![CDATA[Conventional Commits 常见规范]]> Heck <@hecks.tk> Mon, 18 May 2026 08:53:34 +0000 https://www.heckjj.com/post/685/
这一用法源于 [Conventional Commits（约定式提交）](https://www.conventionalcommits.org/) 规范，该规范通过标准化提交信息格式，提升团队协作效率，并便于自动生成变更日志（changelog）和版本号管理。

---

常见提交类型前缀含义

- `feat`：新增功能（feature）  
  示例：`feat: 添加用户登录功能`
- `fix`：修复 bug  
  示例：`fix: 修复登录超时问题`
- `docs`：仅修改文档  
  示例：`docs: 更新 README 使用说明`
- `style`：代码样式调整（不影响运行）  
  示例：`style: 格式化代码缩进`
- `refactor`：代码重构（非新增功能、非修复 bug）  
  示例：`refactor: 提取用户验证逻辑为独立函数`
- `chore`：构建过程或工具依赖更新  
  示例：`chore: 更新 npm 依赖包`
- `test`：增加或修改测试  
  示例：`test: 添加登录接口单元测试`

---

提交信息结构（Conventional Commits）

标准格式为：

```
():
[body]
[footer]
```

- `type`：必须，如 `feat`、`fix` 等  
- `scope`：可选，限定影响范围，如 `(auth)`、`(api)`  
- `subject`：简短描述（≤50 字符）  
- `body` / `footer`：可选，详细说明或关联 issue

示例完整写法：

```bash
feat(auth): 添加 Google OAuth 登录支持

- 允许用户通过 Google 账号一键登录
- 集成 OAuth2.0 流程
- 关联 JIRA-123
```

---

实践意义

- ✅ 提高可读性：团队成员快速理解提交目的  
- ✅ 支持自动化：工具（如 `semantic-release`）可依据 `feat` 自动升级版本号  
- ✅ 便于生成 changelog：按类型分类生成发布说明  

更多规范细节可参考：[Conventional Commits 官方规范](https://www.conventionalcommits.org/) ]]> https://www.heckjj.com/post/684/ <![CDATA[团队 Git 使用规范]]> Heck <@hecks.tk> Mon, 18 May 2026 08:29:14 +0000 https://www.heckjj.com/post/684/
版本：v1.0.0
最后更新：2026年
适用范围：所有项目

目录
分支管理规范
提交信息规范
工作流程规范
代码审查规范
命名规范
安全规范
工具与配置
常见场景处理
1. 分支管理规范
1.1 分支类型
主分支（Main Branches）
main / master

用途：生产环境代码
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送，禁止强制推送
develop

用途：开发环境代码，日常开发集成
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送
辅助分支（Supporting Branches）
feature/* - 功能开发分支

命名：feature/功能名称，如 feature/user-login
来源：从 develop 创建
目标：合并回 develop
生命周期：功能完成后删除
fix/* - Bug 修复分支

命名：fix/问题描述，如 fix/login-button-bug
来源：从 develop 创建
目标：合并回 develop
生命周期：修复完成后删除
hotfix/* - 紧急修复分支

命名：hotfix/紧急修复描述，如 hotfix/security-patch
来源：从 main 创建
目标：合并回 main 和 develop
生命周期：修复完成后删除
release/* - 发布准备分支

命名：release/版本号，如 release/1.0.0
来源：从 develop 创建
目标：合并回 main 和 develop
生命周期：发布完成后删除
1.2 分支命名规则
✅ 允许的命名：

使用小写字母
使用连字符 - 分隔单词
简洁但描述性
示例：feature/user-authentication、fix/payment-error
❌ 禁止的命名：

使用大写字母
使用下划线或空格
使用个人名称
使用特殊字符
示例：Feature/Login、fix_bug、zhangsan-feature
1.3 分支保护规则
main 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
✅ 禁止删除分支
develop 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
2. 提交信息规范
2.1 提交信息格式
<类型>(<范围>): <简短描述>

<详细描述（可选）>

<相关 Issue（可选）>

2.2 类型（Type）
类型  说明  示例
feat  新功能  feat(用户): 添加用户登录功能
fix  修复 Bug  fix(登录): 修复登录按钮点击无效的问题
docs  文档更新  docs: 更新 API 文档
style  代码格式调整  style: 修复代码缩进问题
refactor  代码重构  refactor(服务): 重构用户服务层
perf  性能优化  perf(数据库): 优化查询性能
test  测试相关  test: 添加登录功能单元测试
chore  构建/工具相关  chore: 更新依赖包版本
ci  CI/CD 配置  ci: 添加自动化测试流程
2.3 范围（Scope）
范围是可选的，用于标识提交影响的部分：

模块名：feat(用户): ...
文件名：fix(api.js): ...
组件名：feat(登录): ...
2.4 提交信息示例
✅ 好的提交信息：

feat(用户): 添加用户注册功能

实现了用户注册的完整流程：
- 添加注册表单验证
- 实现邮箱验证功能
- 添加密码加密存储

Closes #123
fix(支付): 修复支付接口超时问题

修复了支付接口在高峰期超时的问题，增加重试机制。

Fixes #456
❌ 不好的提交信息：

更新代码
修复bug
提交
WIP

2.5 提交频率
✅ 推荐：小步提交，完成一个小功能就提交
✅ 推荐：每个提交解决一个问题
❌ 禁止：大量不相关的更改放在一个提交中
❌ 禁止：提交无法编译或测试失败的代码
3. 工作流程规范
3.1 日常开发流程
开始新功能
# 1. 确保 develop 分支是最新的
git checkout develop
git pull origin develop

# 2. 创建功能分支
git checkout -b feature/user-login

# 3. 开始开发
# ... 编写代码 ...
开发过程
# 1. 查看修改状态
git status

# 2. 添加修改到暂存区
git add .

# 3. 提交更改
git commit -m "feat(用户): 实现登录功能"

# 4. 定期推送到远程
git push origin feature/user-login
完成功能
# 1. 确保代码通过测试
npm test

# 2. 确保代码符合规范
npm run lint

# 3. 推送到远程
git push origin feature/user-login

# 4. 在平台创建 Pull Request

3.2 Pull Request 流程
创建 Pull Request
填写信息：

清晰的标题
详细的描述
关联相关 Issue
添加截图（如适用）
检查清单：

代码已通过测试
已更新相关文档
已遵循代码规范
无控制台错误
已关联相关 Issue
请求审查：

指定至少 1 位审查者
添加相关标签
Pull Request 模板
## ???? 变更描述
简要描述本次 PR 的变更内容

## ???? 变更类型
- [ ] 新功能 (feat)
- [ ] Bug 修复 (fix)
- [ ] 文档更新 (docs)
- [ ] 代码重构 (refactor)
- [ ] 性能优化 (perf)
- [ ] 测试相关 (test)
- [ ] 其他 (chore)

## ???? 测试说明
描述如何测试这些变更

## ???? 截图（如适用）
添加相关截图或演示

## ✅ 检查清单
- [ ] 代码已通过测试
- [ ] 已更新相关文档
- [ ] 已遵循代码规范
- [ ] 无控制台错误
- [ ] 已关联相关 Issue

## ???? 相关 Issue
Closes #123

3.3 代码审查流程
审查者职责
及时响应：24 小时内响应审查请求

仔细审查：

代码功能正确性
代码质量和风格
性能和安全问题
测试覆盖
提供反馈：

建设性的意见
具体的改进建议
必要时提供代码示例
提交者职责
及时回复：及时回复审查意见
积极修改：根据反馈修改代码
保持沟通：对审查意见有疑问及时沟通
3.4 合并后清理
# 1. 切换到主分支
git checkout develop
git pull origin develop

# 2. 删除本地分支
git branch -d feature/user-login

# 3. 删除远程分支（如果 PR 合并时未自动删除）
git push origin --delete feature/user-login

4. 代码审查规范
4.1 审查检查清单
功能正确性：代码实现了预期功能
代码质量：代码清晰、可读、可维护
代码风格：遵循团队代码规范
性能：没有明显的性能问题
安全性：没有安全漏洞
错误处理：错误处理完善
测试：有足够的测试覆盖
文档：必要文档已更新
4.2 审查意见格式
✅ 好的审查意见：

这里可以优化一下，使用更简洁的方式：

```javascript
// 当前代码
const result = array.filter(item => item > 0).map(item => item * 2);

// 建议
const result = array.reduce((acc, item) => {
  if (item > 0) acc.push(item * 2);
  return acc;
}, []);

❌ 不好的审查意见：

这个不对
不好
需要改

4.3 审查状态
✅ 批准（Approve）：代码可以合并
⚠️ 需要修改（Request Changes）：需要修改后才能合并
???? 评论（Comment）：有疑问或建议，但不阻止合并
5. 命名规范
5.1 分支命名
见 分支管理规范

5.2 提交信息命名
见 提交信息规范

5.3 文件命名
使用小写字母
使用连字符或下划线分隔
避免使用空格和特殊字符
示例：user-service.js、user_model.py
6. 安全规范
6.1 敏感信息管理
❌ 禁止提交：

密码、密钥、Token
API 密钥
数据库连接字符串
个人隐私信息
配置文件中的敏感信息
✅ 正确做法：

使用环境变量
使用 .gitignore 排除敏感文件
使用密钥管理服务
提供 .env.example 模板
6.2 .gitignore 配置
# 环境变量
.env
.env.local
.env.*.local

# 密钥和证书
*.key
*.pem
*.cert
secrets/
*.secret

# 配置文件
config/production.json
config/local.json

# 日志文件
*.log
logs/

# 临时文件
*.tmp
*.temp
*.cache


6.3 访问控制
使用 SSH Keys 而非密码
定期轮换访问密钥
遵循最小权限原则
离职员工及时撤销权限
7. 工具与配置
7.1 必需工具
Git：版本 >= 2.30.0
代码托管平台：GitHub / GitLab / Gitee
代码审查工具：平台内置或第三方工具
7.2 推荐工具
Git GUI：SourceTree、GitKraken、GitHub Desktop
IDE 集成：VS Code、WebStorm、IntelliJ IDEA
提交信息检查：commitlint、husky
7.3 Git 配置
# 设置用户信息
git config --global user.name "你的姓名"
git config --global user.email "your.email@example.com"

# 设置默认编辑器
git config --global core.editor "code --wait"

# 设置默认分支名
git config --global init.defaultBranch main

# 启用颜色输出
git config --global color.ui true

# 设置推送行为
git config --global push.default simple

8. 常见场景处理
8.1 处理合并冲突
拉取最新代码：git pull origin develop
查看冲突文件：git status
手动解决冲突
标记已解决：git add <file>
完成合并：git commit
8.2 紧急修复（Hotfix）
# 1. 从 main 创建 hotfix 分支
git checkout main
git pull origin main
git checkout -b hotfix/critical-bug

# 2. 修复问题并提交
git add .
git commit -m "fix: 修复紧急问题"
git push origin hotfix/critical-bug

# 3. 创建 Pull Request 合并到 main

# 4. 合并后同步到 develop
git checkout develop
git merge main
git push origin develop

8.3 撤销误提交
# 撤销未推送的提交
git reset --soft HEAD~1  # 保留更改在暂存区
git reset HEAD~1         # 保留更改在工作区
git reset --hard HEAD~1  # 丢弃所有更改（危险！）

# 撤销已推送的提交（推荐使用 revert）
git revert HEAD
git push origin branch-name

8.4 保存临时更改
# 保存当前更改
git stash

# 查看保存的更改
git stash list

# 恢复更改
git stash pop

9. 违规处理
9.1 违规行为
❌ 直接推送到保护分支
❌ 强制推送到共享分支
❌ 提交无法编译的代码
❌ 提交敏感信息
❌ 使用不规范的分支命名
❌ 提交信息不规范
9.2 处理措施
第一次：提醒并指导正确做法
多次违规：团队内讨论，必要时限制权限
严重违规：影响项目安全或稳定性时，立即处理
10. 更新与维护
10.1 规范更新
规范的更新需要团队讨论通过
更新后及时通知所有成员
更新版本号和日期
10.2 培训
新成员入职时进行 Git 规范培训
定期组织 Git 使用技巧分享
提供详细的文档和示例
附录
A. 快速参考
# 开始新功能
git checkout develop && git pull && git checkout -b feature/name

# 提交更改
git add . && git commit -m "feat: 描述" && git push

# 同步主分支
git checkout develop && git pull origin develop

# 查看状态
git status && git log --oneline -5

B. 相关文档
Git 基础入门
团队协作基础
团队协作注意事项
进阶技巧与最佳实践
推荐团队实践
C. 联系方式
如有问题或建议，请联系：

团队负责人：xxx
技术负责人：xxx
文档维护：xxx
]]> https://www.heckjj.com/post/683/ <![CDATA[Git多分支规范]]> Heck <@hecks.tk> Mon, 18 May 2026 08:17:27 +0000 https://www.heckjj.com/post/683/ Git分支管理是指在Git版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。
简单说，就像一棵树的主干和分支，master分支是主干，feature分支是枝叶，每个分支都可以独立生长，最后再合并到主干。
其核心作用包括：
  
• 并行开发：多个功能可以同时开发而不相互干扰。
  
• 代码隔离：开发分支、测试分支、生产分支相互隔离。
  
• 版本管理：支持版本回退、热修复和发布管理。
  
• 团队协作：多人协作时减少代码冲突。
  
二、分支类型说明
2.1 长期存在分支（核心基础分支）
master 主分支
  
• 定位：生产环境分支，存放已发布的稳定、可靠版本代码。
  
• 核心规则：仅用于发布新版本，禁止直接修改或提交新功能。
  
develop 开发分支
  
• 定位：日常开发主分支，汇总当前所有正在推进的功能和任务。
  
• 核心规则：所有新功能开发、改进、优化均从该分支发起，完成后最终合并回此分支。
  
2.2 临时创建分支（辅助开发/发布分支，完成后删除）
feature 功能分支
  
• 创建来源：从 develop 分支创建，功能分支的名字，可以采用feature-*的形式命名
  
• 用途：单独开发某一个新功能（一个功能对应一个分支）
  
• 流转终点：功能实现、测试完成后，合并回 develop 分支
  
release 发布分支（不一定用）
  
• 创建来源：从 develop 分支创建
  
• 用途：为即将发布的版本做最终准备，仅开展测试、bug修复、文档检查等工作（不新增功能）
  
• 流转终点：准备完成且测试通过后，同时合并回 master 分支（作为新发布版本）和 develop 分支（同步发布前的修复内容）
  
hotfix 紧急修复分支
  
• 创建来源：从 master 分支创建
  
• 用途：紧急修复生产环境（master 分支对应版本）中出现的问题
  
• 流转终点：修复完成后，同时合并回 master 分支（更新生产版本）和 develop 分支（同步修复内容，避免后续版本复现问题）
  
三、业务流程图
sequenceDiagram
    participant M as Master分支
    participant D as Develop分支
    participant F as Features功能分支
    participant B as Bugfix缺陷分支
    participant DT as 开发测试环境
    participant PT as 生产测试环境
    %% 功能开发流程（标注关键测试节点）
    note over M,D: 功能开发阶段
    M->>D: 从master初始化develop分支
    D->>F: 基于develop创建功能分支
    F->>DT: 开发完成→直接发布到开发测试环境（第一轮测试）
    note over F,DT: 开发联调阶段
    DT->>F: 反馈联调问题
    F->>F: 在功能分支修复问题
    F->>D: 修复完成→合并到develop分支
    D->>DT: 合并后→再次发布到开发测试环境（第二轮验证）
    DT->>F: 开发测试通过
    F->>M: 功能分支合并到master分支
    M->>PT: master发布到生产测试环境
    %% 缺陷修复流程（标注合并develop再测试）
    note over M,PT: 缺陷修复阶段
    PT->>M: 反馈生产测试缺陷问题
    M->>B: 基于master创建Bugfix缺陷分支
    B->>B: 在Bugfix分支修复缺陷问题
    B->>D: Bugfix分支→合并缺陷修复到develop
    D->>DT: 合并后→发布到开发测试环境联调
    DT->>D: 缺陷联调测试通过
    D->>M: develop→合并缺陷修复到master
    M->>PT: master再次发布到生产测试验收
    M->>M: 验收通过，创建版本标签
点击在新窗口中浏览此图片
四、常见分支策略
  
• master：生产环境代码，标签标记版本
  
• develop：开发主分支，集成功能分支
  
• feature：功能开发分支，从develop创建
  
• release：发布准备分支，从develop/master创建
  
• hotfix：紧急修复分支，从master创建
  
五、分支命名规范
  
• 功能分支：feature/功能名称 或 feature/issue-id-功能描述
  
• 发布分支：release/v1.2.0 或 release/2027-01-01
  
• 热修复分支：hotfix/bug-id 或 hotfix/紧急修复描述
  
• 开发分支：develop 或 development
  
六、互联网大厂Git工作流实战 devops
点击在新窗口中浏览此图片
七、分支管理最佳实践
  
• 分支生命周期管理：及时删除已合并的分支
  
• 保护主分支：通过分支保护规则防止直接推送
• 代码审查：所有合并都需要Pull Request和审查
• 定期同步：保持分支与主分支的同步
  
• 标签管理：重要版本打tag标记
  
八、Git多分支实战和代码合并规范讲解
8.1 Git分支基本操作实战
# 查看当前分支
git branch
# 创建新分支（基于当前分支）
git branch feature/user-login
# 创建并切换到新分支
git checkout -b feature/user-login
# 基于指定分支创建新分支
git checkout -b feature/payment develop
# 查看所有分支（包括远程）
git branch -a
8.2 分支工作流完整演练
功能开发工作流
# 1. 从develop分支创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/user-registration
# 2. 开发功能并提交
# ... 开发代码 ...
git add .
git commit -m "feat: 增加用户注册功能"
# 3. 推送分支到远程
git push origin feature/user-registration
# 4. 创建Pull Request/Merge Request
# 在GitHub/GitLab上创建PR
# 5. 同步最新代码
git checkout develop
git pull origin develop
git checkout feature/user-registration
# 6. 解决可能的冲突
# ... 解决冲突 ...
# 7. 推送更新后的分支
git push origin feature/user-registration --force-with-lease
紧急修复工作流
# 1. 从master创建热修复分支
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug-fix
# 2. 修复bug
# ... 修复代码 ...
git add .
git commit -m "fix: 解决严重的授权问题"
# 3. 同时合并到master和develop
git checkout master
git merge hotfix/critical-bug-fix
git push origin master
git checkout develop
#将热修复代码合并到develop分支，同步修复逻辑到开发分支。
git merge hotfix/critical-bug-fix
git push origin develop
# 4. 删除热修复分支
git branch -d hotfix/critical-bug-fix
代码合并规范说明
提交信息规范
# 格式：type(scope): description
git commit -m "feat(授权): 增加JWT授权验证"
# 常用type：
# feat: 新功能
# fix: 修复bug
# docs: 文档更新
# style: 代码格式调整
# refactor: 代码重构
# test: 测试相关
分支命名规范
  
• 功能分支：feature/功能名称 或 feature/issue-123-user-login
  
• 修复分支：fix/bug描述 或 fix/issue-456-data-validation
  
• 发布分支：release/v1.2.0
  
• 热修复：hotfix/紧急修复描述
  
合并请求规范
• 标题清晰描述变更内容
  
• 详细描述变更原因和影响
  
• 关联相关issue或需求
  
• 提供测试说明和验证步骤
Tags - ]]> https://www.heckjj.com/post/653/ <![CDATA[/bin/bash^M: bad interpreter: No such file or directory]]> Heck <@hecks.tk> Mon, 21 Aug 2023 05:42:40 +0000 https://www.heckjj.com/post/653/ 在执行shell脚本的时候，报错：/bin/bash^M: bad interpreter: No such file or directory。
是由于该脚本文件是在Windows平台编写，然后在MacOS或者Kylin-Server平台中执行。
在Windows平台上文件是dos格式，换行符尾\r\n，而MacOS或者Kylin-Server平台文件是unix格式，换行符尾\n。因此在运行脚本文件时，不能正确解析\r，导致编译错误、运行失败。

解决方案

在MacOS或者Kylin-Server平台上，打开命令行工具执行命令vim *.sh（编辑你的脚本文件），然后执行命令:set ff=unix，最后执行:wq( 保存退出)即可。
]]> https://www.heckjj.com/post/649/ <![CDATA[linux同步时间命令有哪些]]> Heck <@hecks.tk> Thu, 29 Jun 2023 07:02:32 +0000 https://www.heckjj.com/post/649/
1、hwclock命令，可以让系统时间和硬件时间的同步，例“hwclock -w”或“hwclock -s”；
2、ntpdate命令，可以让不同机器间同步时间。


在Windwos中，系统时间的设置很简单，界面操作，通俗易懂，而且设置后，重启，关机都没关系。系统时间会自动保存在BIOS时钟里面，启动计算机的时候，系统会自动在BIOS里面取硬件时间，以保证时间的不间断。

但在Linux下，默认情况下，系统时间和硬件时间并不会自动同步。在Linux运行过程中，系统时间和硬件时间以异步的方式运行，互不干扰。硬件时间的运行，是靠BIOS电池来维持，而系统时间，是用CPU Tick来维持的。在系统开机的时候，会自动从BIOS中取得硬件时间，设置为系统时间。

1. Linux系统时间的设置
在Linux中设置系统时间，可以用date命令：

//查看时间

[root@node1 ~]# date

Tue Feb 25 20:15:18 CST 2014

//修改时间

[root@node1 ~]# date -s "20140225 20:16:00"  #yyyymmdd hh:mm:ss

Tue Feb 25 20:16:00 CST 2014

//date 有多种时间格式可接受，查看date --help

2. Linux硬件时间的设置
硬件时间的设置，可以用hwclock或者clock命令。两者基本相同，只用一个就行，只不过clock命令除了支持x86硬件体系外，还支持Alpha硬件体系。

//查看硬件时间可以是用hwclock ，hwclock --show 或者 hwclock -r

[root@node1 ~]# hwclock --show

Tue 25 Feb 2014 08:21:14 PM CST -0.327068 seconds

//设置硬件时间

[root@node1 ~]# hwclock --set --date "20140225 20:23:00"

[root@node1 ~]# hwclock

Tue 25 Feb 2014 08:23:04 PM CST -0.750440 seconds

3. 系统时间和硬件时间的同步
同步系统时间和硬件时间，可以使用hwclock命令。

//以系统时间为基准，修改硬件时间

[root@node1 ~]# hwclock --systohc <== sys（系统时间）to（写到）hc（Hard Clock）

//或者

[root@node1 ~]# hwclock -w

//以硬件时间为基准，修改系统时间

[root@node1 ~]# hwclock --hctosys

//或者

[root@node1 ~]# hwclock -s

4. 不同机器之间的时间同步
为了避免主机时间因为长期运行下所导致的时间偏差，进行时间同步（synchronize）的工作是非常必要的。Linux系统下，一般使用ntp服务器来同步不同机器的时间。一台机器，可以同时是ntp服务端和ntp客户端。在生产系统中，推荐使用像DNS服务器一样分层的时间服务器来同步时间。

不同机器间同步时间，可以使用ntpdate命令，也可以使用ntpd服务。

4.1 ntpdate命令

使用ntpdate比较简单。格式如下：


1 [root@node1 ~]# ntpdate [NTP IP/hostname]

2 [root@node1 ~]# ntpdate 192.168.0.1

3 [root@node1 ~]# ntpdate time.ntp.org

但这样的同步，只是强制性的将系统时间设置为ntp服务器时间。如果CPU Tick有问题，只是治标不治本。所以，一般配合cron命令，来进行定期同步设置。比如，在crontab中添加：

0 12 * * * /usr/sbin/ntpdate 192.168.0.1

这样，会在每天的12点整，同步一次时间。ntp服务器为192.168.0.1。

或者将下列脚本添加到/etc/cron.hourly/，这样就每小时会执行一次同步：

#!/bin/bash

#

# $Id: sync-clock,v 1.6 2009/12/23 15:41:29 jmates Exp $

#

# Use ntpdate to get rough clock sync with department of Genome Sciences

# time server.



NTPDATE=/usr/sbin/ntpdate

SERVER="192.168.0.1 "


# if running from cron (no tty available), sleep a bit to space

# out update requests to avoid slamming a server at a particular time

if ! test -t 0; then

  MYRAND=$RANDOM

  MYRAND=${MYRAND:=$$}



  if [ $MYRAND -gt 9 ]; then

    sleep `echo $MYRAND | sed 's/.*\(..\)$/\1/' | sed 's/^0//'`

  fi

fi



$NTPDATE -su $SERVER

# update hardware clock on Linux (RedHat?) systems

if [ -f /sbin/hwclock ]; then

  /sbin/hwclock --systohc

fi

4.2 ntpd服务

使用ntpd服务，要好于ntpdate加cron的组合。因为，ntpdate同步时间会造成时间的突变和跳跃，对一些依赖时间的程序和服务会造成影响。比如sleep，timer等。而且ntpd服务可以在修正时间的同时，修正CPU Tick。因此理想的做法为，在开机的时候，使用ntpdate强制同步时间，在其他时候使用ntpd服务来同步时间。

要注意的是，ntpd 有一个自我保护的机制：如果本机与上源时间相差太大，ntpd 不会运行时间同步操作，所以新设置的时间服务器一定要先 ntpdate 从上源取得时间初值, 然后启动 ntpd服务。ntpd服务运行后，先是每64秒与上源NTP服务器同步一次，根据每次同步时测得的误差值经复杂计算逐步调整自己的时间，随着误差减小，逐步增加同步的间隔。每次跳动，都会重复这个调整的过程。

4.3. ntpd服务的设置

ntpd服务的相关设置文件如下：

（1）/etc/ntp.conf：这个是NTP daemon的主要设文件，也是 NTP 唯一的设定文件。

（2）/usr /share/zoneinfo/：在这个目录下的文件其实是规定了各主要时区的时间设定文件，例如北京地区的时区设定文件在 /usr/share/zoneinfo/Asia/Shanghai 就是了。这个目录里面的文件与底下要谈的两个文件(clock 与localtime)是有关系的。

（3）/etc/sysconfig/clock：这个文件其实也不包含在NTP 的 daemon 当中，因为这个是 Linux 的主要时区设定文件。每次开机后，Linux 会自动的读取这个文件来设定自己系统所默认要显示的时间。

（4）/etc /localtime：这个文件就是"本地端的时间配置文件"。刚刚那个clock 文件里面规定了使用的时间设置文件(ZONE) 为 /usr/share/zoneinfo/Asia/Shanghai ，所以说，这就是本地端的时间了，此时， Linux系统就会将Shanghai那个文件另存为一份 /etc/localtime文件，所以未来我们的时间显示就会以Beijing那个时间设定文件为准。

下面重点介绍 /etc/ntp.conf文件的设置。在 NTP Server 的设定上，建议不要对Internet 无限制的开放，尽量仅提供局域网内部的 Client 端联机进行网络校时。此外，NTP Server 总也是需要网络上面较为准确的主机来自行更新自己的时间啊，所以在我们的 NTP Server 上面也要找一部最靠近自己的 Time Server 来进行自我校正。事实上， NTP 这个服务也是 Server/Client 的一种模式。

[root@linux ~]# vi /etc/ntp.conf

# 1. 关于权限设定部分

#　　权限的设定主要以 restrict 这个参数来设定，主要的语法为：

# 　　restrict IP mask netmask_IP parameter

# 　　其中 IP 可以是软件地址，也可以是 default ，default 就类似 0.0.0.0

#　　至于 paramter 则有：

#　　　ignore　：关闭所有的 NTP 联机服务

#　　　nomodify：表示 Client 端不能更改 Server 端的时间参数，不过Client 端仍然可以透过 Server 端来进行网络校时。

#　　　notrust ：该 Client 除非通过认证，否则该 Client 来源将被视为不信任网域

#　　　noquery ：不提供 Client 端的时间查询


#　　　notrap ：不提供trap这个远程事件登入


#　　如果 paramter 完全没有设定，那就表示该 IP (或网域)"没有任何限制"


restrict default nomodify notrap noquery　# 关闭所有的 NTP 要求封包

restrict 127.0.0.1　　　 #这是允许本机查询

restrict 192.168.0.1 mask 255.255.255.0 nomodify


#在192.168.0.1/24网段内的服务器就可以通过这台NTP Server进行时间同步了

# 2. 上层主机的设定

#　　要设定上层主机主要以 server 这个参数来设定，语法为：

#　　server [IP|HOST Name] [prefer]

#　　Server 后面接的就是上层 Time Server，而如果 Server 参数


# 后面加上 perfer 的话，那表示我们的 NTP 主机主要以该部主机来


# 作为时间校正的对应。另外，为了解决更新时间封包的传送延迟动作，

#　　所以可以使用 driftfile 来规定我们的主机

#　　在与 Time Server 沟通时所花费的时间，可以记录在 driftfile  

#　　后面接的文件内，例如下面的范例中，我们的 NTP server 与  

#　　cn.pool.ntp.org联机时所花费的时间会记录在 /etc/ntp/drift文件内

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server cn.pool.ntp.org prefer

#其他设置值，以系统默认值即可
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay  0.008

keys /etc/ntp/keys

总结一下，restrict用来设置访问权限，server用来设置上层时间服务器，driftfile用来设置保存漂移时间的文件。

4.4 ntpd服务的启动与查询

在启动NTP服务前，先对提供服务的这台主机手动的校正一次时间（因为启动服务器，端口会被服务端占用，就不能手动同步时间了）。

[root@node1 ~]# ntpdate cn.pool.ntp.org

25 Feb 21:10:52 ntpdate[9549]: adjust time server 202.112.31.197 offset 0.000101 sec

然后，启动ntpd服务：

[root@node1 ~]# /etc/init.d/ntpd start

Starting ntpd: [ OK ]

[root@node1 ~]# date

Tue Feb 25 21:11:07 CST 2014

查看端口（ntpd服务使用UDP的123端口）：

[root@node1 ~]# netstat -ln |grep :123

udp 0 0 12.12.12.100:123 0.0.0.0:*

udp 0 0 192.168.0.100:123 0.0.0.0:*

udp 0 0 172.18.226.174:123 0.0.0.0:*

udp 0 0 10.10.10.100:123 0.0.0.0:*

udp 0 0 127.0.0.1:123 0.0.0.0:*

udp 0 0 0.0.0.0:123 0.0.0.0:*

udp 0 0 fe80::225:90ff:fe98:61ff:123 :::*

udp 0 0 fe80::225:90ff:fe98:61fe:123 :::*

udp 0 0 fe80::202:c903:1b:afa1:123 :::*

udp 0 0 ::1:123 :::*

udp 0 0 :::123 :::*

如何确认我们的NTP服务器已经更新了自己的时间呢？

[root@node1 ~]# ntpstat

synchronised to NTP server (202.120.2.101) at stratum 4

time correct to within 557 ms

polling server every 64 s

# 该指令可列出NTP服务器是否与上层联机。由上述输出结果可知，时间校正约

# 为557*10(-6)秒，且每隔64秒会主动更新时间。

常见的错误：

unsynchronized time server re-starting polling server every 64 s

// 或者

25 Apr 15:30:17 ntpdate[11520]: no server suitable for synchronization found

其实，这不是一个错误。而是由于每次重启NTP服务器之后大约要3－5分钟客户端才能与server建立正常的通讯连接。当此时用客户端连接服务端就会报这样的信息。一般等待几分钟就可以了。

[root@node1 ~] # ntptrace –n

127.0.0.1:stratum 11, offset 0.000000，synch distance 0.950951

222.73.214.125：stratum 2，offset –0.000787，synch distance 0.108575

209.81.9.7:stratum 1，offset 0.000028，synch distance 0.00436，refid 'GPS'

# 这个指令可以列出目前NTP服务器（第一层）与上层NTP服务器（第二层）

# 彼此之间的关系，注意：该命令需要安装ntp-perl包

ntpq命令：


[root@node1 ~]# ntpq -p

在这里插入图片描述

指令"ntpq -p"可以列出目前我们的NTP与相关的上层NTP的状态，以上的几个字段的意义如下：

remote：即NTP主机的IP或主机名称。注意最左边的符号，如果由"+“则代表目前正在作用钟的上层NTP，如果是”*"则表示也有连上线，不过是作为次要联机的NTP主机。

refid：参考的上一层NTP主机的地址

st：即stratum阶层

when：几秒前曾做过时间同步更新的操作

poll：下次更新在几秒之后

reach：已经向上层NTP服务器要求更新的次数

delay：网络传输过程钟延迟的时间

offset：时间补偿的结果

jitter：Linux系统时间与BIOS硬件时间的差异时间

最后提及一点，ntp服务默认只会同步系统时间。如果想要让ntp同时同步硬件时间，可以设置/etc/sysconfig/ntpd 文件。

在/etc/sysconfig/ntpd文件中，添加 SYNC_HWCLOCK=yes 这样，就可以让硬件时间与系统时间一起同步。 ]]> https://www.heckjj.com/post/641/ <![CDATA[MinIO 服务器配置（配置目录）]]> Heck <@hecks.tk> Thu, 12 Jan 2023 07:09:44 +0000 https://www.heckjj.com/post/641/
但是从 RELEASE.2018-08-18T03-49-57Z 之后的版本开始，配置文件已迁移到存储数据的 .minio.sys/config 目录（存储后端是启动服务器时传递给 MinIO 服务器的目录）。如果使用如下命令启动 MinIO 服务：


minio.exe server D:/tmp/data
则配置文件位于 D:\tmp\data\.minio.sys\config 目录中。

注意：你可以使用 mc -h 命令查看当前 MinIO 的版本信息，如下：


D:\server\minio>mc -h
NAME:
  mc - MinIO Client for cloud storage and filesystems.
...
VERSION:
  RELEASE.2021-06-13T17-48-22Z
您可以使用 --config-dir 指定现有配置的位置，MinIO 会自动将 config.json 迁移到您的后端存储。您当前 --config-dir 指定的 config.json 配置文件将在成功迁移后重命名为 config.json.deprecated。

如果你的配置文件位于 C:\Users\Administrator\.minio\config.json，MinIO 会自动将 config.json 中的配置迁移到 D:\tmp\data\.minio.sys\config\config.json 文件，然后将 C:\Users\Administrator\.minio\config.json 重命名为 C:\Users\Administrator\.minio\config.json.deprecated。

此外 --config-dir 现在是一个遗留选项，计划在将来删除，因此请相应地更新您的本地启动和 ansible 脚本。使用如下命令去启动 MinIO 服务：

minio.exe server D:\tmp\data
上面命令，将创建的存储桶以及存储桶中的对象放到 D:\tmp\data 目录，并且配置信息均位于 D:\tmp\data\.minio.sys 目录。

]]> https://www.heckjj.com/post/640/ <![CDATA[Linux安装MinIO]]> Heck <@hecks.tk> Thu, 12 Jan 2023 05:06:57 +0000 https://www.heckjj.com/post/640/ cd /opt
mkdir minio
第二步，wget下载安装包：
https://dl.minio.io/server/minio/release/linux-amd64/minio

第三步，进入minio文件夹创建log文件
cd /minio
touch minio.log


第四步，赋予minio文件执行权限

chmod 777 minio
第五步，启动minio
./minio server /opt/minio/data （/opt/minio/data 为你存放静态文件的目录）


这个时候我们看下面爆红的提示，说的是：
警告：控制台端点正在侦听动态端口 (39175)，请使用 --console-address “:PORT” 选择静态端口。
警告：检测到默认凭据“minioadmin:minioadmin”，我们建议您使用“MINIO_ROOT_USER”和“MINIO_ROOT_PASSWORD”环境变量更改这些值

所以我们按照提示来：


export MINIO_ROOT_USER=fileadmin
export MINIO_ROOT_PASSWORD=fileadmin
第六步，重新启动minio
./minio server /opt/minio/data （/opt/minio/data 为你存放静态文件的目录）
第七步，设置环境变量
vim /etc/profile
添加

# set minio environment
export MINIO_ROOT_USER=fileadmin
export MINIO_ROOT_PASSWORD=fileadmin
生效：source /etc/profile;

第 七步，设置minio后台启动（指定端口）
vim start.sh

nohup /opt/minio/minio server  /opt/minio/data --console-address ":35555" > /opt/minio/minio.log 2>&1 &
('2>&1’表示现在标准输出直接输入到/opt/minio/minio.log 中，而2>&1是将标准错误重定向到标准输出,‘nohup’和末尾’&'组合使用表示脱离终端后继续执行)
]]> https://www.heckjj.com/post/638/ <![CDATA[让bat批处理以管理员权限运行的实现方法]]> Heck <@hecks.tk> Mon, 12 Dec 2022 07:12:50 +0000 https://www.heckjj.com/post/638/ 有的电脑是非管理员登录，运行程序时，需要提示是否运行运行。解决方法如下：
在批处理开头加上：
适用于无参数

%1 mshta vbscript:CreateObject("Shell.Application").ShellExecute("cmd.exe","/c "^&chr(34)^&"%~0"^&chr(34)^&" ::","%cd%","runas",1)(window.close)&&exit

适用于有参数

%2 mshta vbscript:CreateObject("Shell.Application").ShellExecute("cmd.exe","/c "^&chr(34)^&"%~0"^&chr(34)^&" "^&chr(34)^&"%~1"^&chr(34)^&" ::","%cd%","runas",1)(window.close)&&exit

更多参数的以此类推
运行批处理时多加一个参数::，这句就不会执行
为了兼容8.3短路径，可把%~0等换成%~s0等
理论上是没问题，但启动路径有时不可靠，之后可能还要pushd或cd /d

bat文件以管理员权限运行的几种方式

1、创建bat快捷方式，然后右键快捷方式-->properties-->advanced-->Run as administrator。
2、下载bat转成exe工具，将bat转成exe,然后右键exe-->properties-->Compatibility-->Run as administrator。
3、以管理员权限运行cmd，然后dos框中运行相应的bat。 ]]> https://www.heckjj.com/post/637/ <![CDATA[怎么使用bat脚本更改本地受保护的hosts文件]]> Heck <@hecks.tk> Fri, 09 Dec 2022 14:15:16 +0000 https://www.heckjj.com/post/637/    /E            编辑 ACL 而不替换。
   /G 　　　赋予指定用户访问权限。
   F 　　　完全权限。
点击在新窗口中浏览此图片
Administrators、SYSTEM、Users（是windows用户组需要什么加什么）

attrib 是控制文件属性的

　　+ 添加文件属性

        -  删除文件属性

        R 只读文件属性

        A 存档文件属性

        S 系统文件属性

        H 隐藏文件属性

         I 无连接属性

@echo
@echo 127.0.0.1 .heckjj.com >>E:hosts（这是我们要写入的内容）

虽然脚本比较笨拙，但是亲测有效，若是找不到好的方法可以选择试一下O(∩_∩)O
======================================================================================
1、新建记事本输入一下内容
bat脚本代码如下：

set HOSTS=C:\Windows\System32\drivers\etc\hosts
echo Y|cacls %HOSTS% /E /G Administrators:F
echo Y|cacls %HOSTS% /E /G SYSTEM:F
echo Y|cacls %HOSTS% /E /G Users:F

attrib -r -h %HOSTS%

@echo
@echo.>>%HOSTS%


@echo 127.0.0.1 heckjj.com >>%HOSTS%

attrib +r +h %HOSTS%

title 刷新本地dns缓存并退出
echo 查看修改后的hosts文件内容,1秒后退出!
type "%HOSTS%" |findstr /v "^#"|findstr "[0-9]"
ping -n 1 127.0.0.1>nul
ipconfig /flushdns
echo 刷新本地缓存成功，即将退出!
ping -n 2 127.0.0.1>nul
echo.
exit
2、将记事本后缀名改为.bat格式的文件，然后双击即可完成修改。 ]]>