## 事件简介

当某一天，不知道发生什么事了，突然发现 `Vanblog` 登录一直提示 `用户名和密码错误`，但你十分确定用户名密码都没有错，此时你可能一脸懵逼，又不知道如何解决，此时该怎么办？又是什么原因导致的呢？

下面就说一下老狗发现的一些情况。



## 什么原因导致的？

经过排查，确认你的Vanblog运行没有任何问题，且你没有记错用户名/密码，老狗认为只有一种可能导致这个问题，那就是：**数据库的数据错乱了。** 如果你近期有手动修改数据库，或者备份还原等操作，则大概率是这个原因。

错乱的数据大概率是两个字段：`users` 表中的 `password` 和 `salt`。

> 经过测试发现，`users` 表中的 `password` 和 `salt` 在每次登录之后，会出现变化，即：每次登录成功后，会重新生成 `password` 和 `salt` 的值。
> 
> 逻辑猜想：每次登录成功后，会随机生成一个新的 `salt`，随后再将原 `password` 的真实值进行加密，生成一个新的加密后的 `password`。
>
> 这就是 `password` 和 `salt` 的值会变的原因。

而数据库乱了，大概率是 `password` 和 `salt` 的值不匹配了，有可能是在你近期有手动修改数据库，然后导致的数据混乱。

## 如果解决？

理解了上面的原因后，就大概可以知道有两个方法解决这个问题：
1. 重置密码；
2. 恢复数据。

### 重置密码

在登录页面，点击 `忘记密码` ，然后去服务器的 `Vanblog` 的启动日志中找到服务密钥，即可进行密码重置。

参考官网：https://vanblog.mereith.com/faq/password.html

### 恢复数据

找到上次备份的数据中的 `password` 和 `salt` 对应的值，然后将现在数据库中的值替换为这两个备份的值即可。

如果你没有备份过数据，则需要重置密码。

Vanblog密码错误问题记录

## 简介

经常使用Windows办公的用户，应该都知道 `win + E` 这个快捷键可以快速打开文件资源管理器，老狗也经常使用这个快捷键。

但对于有习惯从盘符寻找文件的用户来说，打开文件资源管理器时默认的展示的内容，和打开 `此电脑` 展示的内容不同，总是会觉得耽误时间，那么有没有什么办法设置打开文件资源管理器时默认展示 `此电脑` 呢？当让可以。

> `此电脑` 指->打开后显示 `C盘/D盘` 等盘符的页面。



## 设置默认行为

> 下面示例以 `Windows11` 为演示，`Windows10` 用户请根据说明自行尝试。

设置默认打开 `此电脑` 很简单，只要找到以下 `文件资源管理器选项` 页面即可。

![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723973531787-0.jpg)

只要打开这个设置界面，在 `常规` 选项卡中的 `打开文件资源管理器时打开` 选择 `此电脑` 即可。

那么如何找到 `文件资源管理器选项` 呢？目前发现了两个方法。

## 如何打开`文件资源管理器选项`

### 1. 开始菜单快速打开

在开始菜单中搜索 `文件资源管理器选项` 即可直接打开上面的设置界面：

![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723973801275-0.jpg)

## 2. 在任意文件夹中打开

在任意的资源管理器页面，打开 `查看更多`，点击 `选项` 即可：

![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723973978114-0.jpg)

Windows10/11设置打开文件资源管理器时默认显示此电脑/磁盘符

## 当前记录如下：

- actions/upload-artifact
- softprops/action-gh-release
- actions/setup-node
- actions/checkout
- docker/login-action



## actions/upload-artifact

作用：一般用于导出 `Workflows` 执行过程中生成的文件，导出后可以在 `Github` 的 `Actions` 执行结果页面底部下载。

基础使用示例：

```yaml
      - name: Upload Artifacts
        uses: actions/upload-artifact@v4
        with:
          name: Build-Files
          path: build/
```

仓库：https://github.com/actions/upload-artifact

## softprops/action-gh-release

作用：用于在 GitHub 仓库中创建发布版本（Release），支持上传构建产物到发布页面。适合在完成打包和构建后，将文件发布到 GitHub Releases 中。

基础使用示例：

```yaml
      - name: Create Release
        uses: softprops/action-gh-release@v2
        with:
          token: ${{ secrets.GH_TOKEN }}
          name: 🎉Release 1.0.0
          tag_name: 1.0.0
          files: build/**/* # 指定要上传的文件
```

仓库：https://github.com/softprops/action-gh-release

## actions/setup-node

作用：用于在 GitHub Actions 中设置指定版本的 Node.js 环境。通常用于安装和管理 Node.js 版本，以确保在 CI/CD 环境中运行的代码版本与开发环境一致。

基础使用示例：

```yaml
      - name: Setup Node.js
        uses: actions/setup-node@v4
```

仓库：https://github.com/actions/setup-node

## actions/checkout

作用：用于检出仓库的代码，通常用于 GitHub Actions 开始时获取最新的代码版本。这是几乎所有 CI/CD Workflow 的第一步。

基础使用示例：

```yaml
      - name: Checkout code
        uses: actions/checkout@v4
```

仓库：https://github.com/actions/checkout

## docker/login-action

作用：用于在 GitHub Actions 中登录到 Docker Hub 或其他 Docker 注册表，以便推送和拉取镜像。通过此操作，可以将登录信息安全地传递到 Docker CLI 中，简化后续的 Docker 操作。

基础使用示例：

```yaml
      - name: Docker Login
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
```

仓库：https://github.com/docker/login-action

Github常用的Actions记录

## 简介：什么是BitLocker？

`BitLocker` 是一项 `Windows` 安全功能，可通过加密驱动器来保护数据。 此加密可确保如果有人尝试脱机访问磁盘，他们将无法读取其任何内容。

如果设备丢失或被盗，`BitLocker` 尤其有价值，因为它可保护敏感信息的安全。 它设计为用户友好，并与 `Windows` 操作系统无缝集成，使其易于设置和管理。

`BitLocker` 提供两个功能：
1. 设备加密：旨在简化使用，并且通常会自动启用
2. BitLocker 驱动器加密：专为高级方案设计，可用于手动加密驱动器

如果你使用了 `BitLocker` ，请你务必学会如何备份和查找 `BitLocker` 恢复密钥，否则一旦忘记或丢失 `BitLocker` 密钥，可能会让你永久丢失你的数据！

### 如果找不到恢复密钥，该怎么办？
1. 如果设备由组织管理，请与 IT 部门联系以检索恢复密钥。
2. 如果找不到 `BitLocker` 恢复密钥，并且无法撤消导致需要它的任何更改，则必须使用 `Windows` 恢复选项之一重置设备。**注意：重置你的设备将删除所有文件。**

**重要: `Microsoft` 支持部门无法提供或重新创建丢失的 `BitLocker` 恢复密钥。**



## 查找密钥

> `BitLocker` 恢复密钥，下文统称 `恢复密钥` 或 `BitLocker密钥`。

### 什么时候需要使用恢复密钥？

当 `BitLocker` 无法在 `Windows` 中自动解锁加密驱动器时，需要 `BitLocker` 恢复密钥。 此密钥是一个 `48` 位数字，用于重新获得对驱动器的访问权限。如以下场景：

1. 在启动期间，系统可能会提示你输入 BitLocker 恢复密钥，因为存在安全风险或硬件更改。
2. 可能需要为数据或外部驱动器提供 BitLocker 恢复密钥，例如，如果忘记了解锁密码。

### 如何查找恢复密钥？

当系统提示输入 `BitLocker` 恢复密钥时，请记下 `恢复密钥ID` 的前 `8` 位数字。当你有多个恢复密钥时，`ID` 有助于确定要使用的那个恢复密钥。 下图中是一个 `恢复密钥ID` 示例：

![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723689600914-0.png)

恢复密钥可能位于多个位置，具体取决于激活 BitLocker 时所做的选择。 

#### 1. 微软账户查找密钥

如果 `BitLocker` 恢复密钥已备份到 `Microsoft` 帐户，请按照以下步骤检索它： 

1. 使用可以联网的设备打开：[https://account.microsoft.com/devices/recoverykey](https://account.microsoft.com/devices/recoverykey) ，登录你的 `Microsoft` 帐户。
2. 根据 `恢复密钥ID` 找到对应的恢复密钥，如下图：
    ![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723690023369-0.png)

> 工作账户或学校账户操作同上。

#### 个人备份

1. 如果你的恢复密钥已经备份到 `U盘`，则可以将 `U盘` 插入锁定的设备，然后按照说明进行操作。（注意：备份到 `U盘` 不是指存储在文件中再保存到 `U盘`，如何备份到 `U盘` 下面会讲）
2. 如果将密钥保存为文本文件，并保存到其他设备上了，请使用其他设备来读取文本文件，从而获取恢复密钥。

## 备份密钥

在大多数情况下，首次激活 `BitLocker` 时会自动备份 `BitLocker` 恢复密钥：

1. 如果使用 `Microsoft` 帐户，则 `BitLocker` 恢复密钥通常附加到该帐户，并且你可以联机访问恢复密钥。
2. 如果使用的是由工作单位或学校管理的设备，则 `BitLocker` 恢复密钥通常由组织的 `IT` 部门备份和管理。 这样做是为了确保在由于某种原因无法访问设备时，组织可以帮助你恢复数据。如果你要使用 `BitLocker` 功能，最好向 `IT` 部门咨询与组织中的 `BitLocker` 恢复相关的特定过程和策略。

**提示：请务必验证此备份是否存在且可访问，或者创建自己的额外备份。**

下面介绍个人备份 `BitLocker` 恢复密钥的操作步骤：

1. 在 “`开始`” 中 ，键入 `BitLocker` ，然后从结果列表中选择 “`管理 BitLocker` ”；
2. 在 `BitLocker` 应用中，选择要备份的驱动器旁边的 “`备份恢复密钥` ” ，如下图（英文版）：
    ![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723690816234-0.png)
3. 点击 `备份恢复密钥` 后，会弹出操作界面，需要选择要备份密钥的位置，一般有如下几种选择：
    - 保存到`Microsoft`帐户：这会将密钥保存在`Microsoft`帐户的恢复密钥库中；如果已登录到工作或学校管理的计算机，则可能显示为“`保存到 Azure AD 帐户`”。
    - 保存到 `U盘`：如果你有一个方便的闪存驱动器，则可以保存该驱动器的密钥。如果设备将来需要恢复密钥，请插入该 `U盘` 并按照说明进行操作。 密钥仅占用几 `KB` 空间，因此驱动器不必很大。（重要: 请勿将带有密钥的 `USB` 闪存驱动器与计算机一起存储。 如果小偷要获取计算机，他们可能会窃取闪存驱动器并绕过 `BitLocker` 加密，使你的数据易受攻击。）
    - 保存到文件：可以在任何设备上将恢复密钥保存为纯文本文件。如果将来需要该文件，只需使用记事本等文本编辑器将其打开即可。 无法将文件保存到 `BitLocker` 加密驱动器，因此，如果设备上没有第二个未加密卷，则可能需要将其保存到 `U盘`。
4. 选择“完成”。

*友情提示：可以根据需要进行任意数量的备份。拥有多个备份不是一个坏主意，只是为了安全！*

Windows10/11备份和查找BitLocker密钥

## 事件简介

今天老狗以自身经历评价一波亚马逊云（`AWS`），总体的评价是有好有坏，经过老狗的这次事件，你认为亚马逊云是好是坏由你自己思考，并且欢迎你的评论。

这起事件简单来说，是由于亚马逊云操作过于复杂（个人认为有些地方不合理），以及个人没有正确操作亚马逊云，从而导致的资源持续扣费事件，涉及金额高达：`273.12 + 79.63 = 352.75 USD`，按当前汇率 `7.16` 计算，折合人民币 `2500` 多元。还好最终通过客服沟通，通过了退款申请！

结果如下：
![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723563457.jpg)

这起事件详细的故事及退款申请过程，请向下看。



## 事件详情

相信很多人互联网人，都知道亚马逊云对新用户有12个月免费资源的优惠政策吧，当你有了一个外币信用卡时，不去白嫖一波都会觉得浪费吧，老狗也不例外。

大概2023年9月左右，注册了亚马逊云账户，12月才有外币信用卡，立马就去绑卡开通了新人免费资格，从此开始了愉快的白嫖时光。

> 老狗主要白嫖的是 `EC2` 虚拟机，除特殊情况，后面统称为免费资源。

白嫖的时光总是过得那么快，时间很快来到2024年七月的某一天，当天老狗正在愉快的使用在免费资源上搭建的工具时，突然网络出现了问题，过了一天还是没有恢复，此时老狗不得不怀疑亚马逊的免费资源出了问题，但奇怪的是，通过 `SSH` 工具链接免费资源是没有问题的，经过各种排查和重启都没有恢复工具使用，因此就在亚马逊云的功能上开始了一通老狗也不知道是干啥的操作。

首先老狗删除了原本的免费资源实例，重新创建了一个新的，但是还是不行，老狗不得不怀疑亚马逊云的功能调整，因此就查看亚马逊云的各种服务，看了半天，找到一个名叫网络防火墙(`Network Firewall`)的功能，所以怀疑是不是防火墙拦截了工具的网络，所以就去尝试创建了一个防火墙，关联上老狗新建的免费资源实例，但不幸的是，仍然没用，工具的网络还是没有恢复。

最终经过多次尝试，发现实在找不到问题，就放弃了亚马逊云的免费资源，转而选择其他服务商。

当然在放弃使用时，老狗知道应该删除所有创建的资源，防止免费时长到期产生费用，因此就在亚马逊控制台一通删除操作，结果在删除一个VPC资源时，一直提示无法删除，一般无法删除都会有`某某某资源占用`的提示，老狗就根据提示一层层的去删除资源，可是当老狗到达删除 `网络 ACL`资源的时候，就没有资源占用的提示了，但是仍然无法删除，这时老狗就懵了，提示截图如下：

![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723563661.jpg)

重复尝试了几次仍然是这样，也没有找到任何其他办法办法，老狗就想当然的以为：“这是 `AWS` 服务延迟，其实后台已经在删除了。”所以最终就将这个资源搁置了。

> PS：很多服务商有删除延迟的设计，因此刻板的产生了联想。

将能删除的资源删除之后，老狗就安心睡觉了，想着 **过几天** 再上亚马逊云看一下，如果还没有删除再想想办法。就是这个简单的 **过几天** ，一不小心就过去了一个月。

直到8月10日左右，老狗检查自己的邮箱，收到了亚马逊云发来的巨额账单，账单如下：

![image](https://images.oldmoon.top/images/dingdangdog/dingdangdog-1723563200.jpg)

在这炎炎夏日，看到这个账单，老狗直接汗流加倍啊，赶忙登录亚马逊云查看情况，结果发现上次的一通操作想要删除的资源，并没有被删除，这才想起来，之前说 **过几天** 再上来看看的事，这已经过去一个多月了。

看到这个账单，不禁冷汗直流，经过老狗长达半小时的深思熟虑，老狗决定发起客服沟通，并申请退款。当然有了这个想法，还需要一些正当的理由，所以老狗就又去试着删除产生这些账单的资源，但是和一个月之前一样，还是提示无法删除，这就给了老狗一个相对正当的理由，毕竟之前想删除，总是提示无法删除啊！

## 工单申诉对话

老狗以无法删除造成收费为由，发起了客服工单，下面是对话记录，由于内容过长，就简写一些，不再贴图，请见谅：

### 1. 发起工单：

> 
> 23年12月，我开始试用免费的EC2资源，大概一个月前(2024年7月)，我使用免费EC2建立的应用出现网络异常，导致我无法正常使用，因此当时尝试删除原有的EC2实例，并尝试重新创建EC2实例和我的应用，但并没有解决问题，因此我将所有EC2实例全部删除，不再使用。但当时出现就出现了VPC无法正常删除的问题，我依据提示寻找不能删除的原因，但并没有找到，所以我以为是EC2删除后的保护机制，就没再关心，今天查看我的邮件，发现在8月3日收到了较为昂贵的AWS账单，可是现在我仍然无法删除这些付费资源，请问这合理吗？这一个月内我几乎没有使用AWS的资源，我是否能够申请退款？
> 
> 下面是我收到的账单邮件原文：
> 
> Greetings from Amazon Web Services,
> 
> This e-mail confirms that your latest billing statement, for the account ending in ****5444, is available on the AWS web site. Your account will be charged the following:
> 
> Total: $273.12
> 
> 等等...

### 2. 客户回复：

> 感谢您联系AWS！
> 
> 很抱歉我们目前仅能以英文回复您，我已经将这个案例转发给中文客服团队。
> 
> 他们将在工作时间周一至周五 9AM-6PM (UTC+08:00) 尽快联系您，感谢您的耐心等候。
> 
> ---
> 下面是中文客服回复：
> 
> 尊敬的客户您好，感谢您联系 AWS 中文帐务团队。
> 
> 明白您对于帐户产生的费用有疑虑并且希望申请帐务调整，我很乐意协助您。 
> 
> 一，费用来源
> 经查询，您账单产生费用的原因并非来自 EC2 资源，而是您在 2024 年 7 月 3 日时创建了 AWS Network Firewall 防火墙，此服务并不在免费套餐的范围中，因此产生了相关的费用。
> 
> 目前您的免费套餐至 2024 年 9 月底才会过期。
> 
> EC2 免费套餐提供 12 个月特定实例类型每个月 750 小时的免费用量、每月 750 小时的公有 IPv4 地址使用量，同时 EBS 免费套餐供应每个月 30 GB 的储存量。
> 更多关于 EC2 免费套餐的资讯： `https://xxx` 
> AWS Network Firewall 定价：`https://xxx`
> 
> 二，停止费用产生
> 由于帐务团队无工具查看您目前防火墙资源的状态，麻烦您参考以下文档透过 VPC 控制台确保防火墙资源已经删除：`https://xxx`
> 
> 三，帐务调整
> 在为您提交帐务调整申请前，麻烦完成以下动作：
> 1. 先将产生费用的资源删除。
> 
> 如果您有其他的问题，您可以点击以下链接，透过支持中心回复本工单，我们将诚挚提供协助：`https://xxx`
> 
> 祝您有个美好的一天！
> 
> 您的回馈是我们进步的动力，邀请您透过支持中心于回复的右上角给予星等评价。

### 3. 删除资源后回复：

> 经过繁琐的操作，现在我终于删除了所有资源，相信以后不会产生费用了。
> 
> 接下来只剩一个问题，前面产生的费用能否申请退款？因为收费期间我没有使用任何相关资源。
> 
> 当然我承认这起事件有我的责任，我没有掌握AWS的使用，导致我产生了这部分损失；但我认为AWS也有一定的责任，在我想删除一些资源时，总是提示无法删除，且根据提示最终没有指向 `Network Firewall` 相关服务，导致我没能正确删除这些付费资源，从而直接导致了这些损失。
> 
> 因此，我想针对这部分资源导致的费用申请退款，不知能否得到肯定的答复？感谢。

### 4. 客服回复

> 亲爱的客户您好，感谢您的配合操作，了解您希望申请 `Firewall` 服务产生的费用帐务调整，我很乐意协助。
> 
> 由于帐单控制台每天更新一次，因此我将等待至下周一金额停止变动后，为您提出 7 月与 8 月相关费用的帐务调整。
> 
> 待后续有结果后，我会主动透过工单通知您。
> 
> 谢谢您对于内部流程的理解。
> 
> 您的回馈是我们进步的动力，邀请您透过支持中心于回复的右上角给予星等评价。
> 
> ---
> 下周一的回复：
> 
> 亲爱的客户您好，
> 
> 感谢您的耐心等待，我已为您提出账款调整申请，很高兴通知您，作为一次性特例，账款调整结果如下：
> 
> - 2024 年 7 月帐单：退款金额 273.12 USD 将返还到您的支付信用卡。
> 
> 要向您说明，返还所需的时间取决于您的信用卡发卡机构，通常需要 7 至 14 个工作天，还请您耐心等候。
> 
> - 2024 年 8 月帐单：提供折扣点数 79.63 USD ，此折扣点数将于月底结账时自动抵扣账单金额。
> 
> 您可以登入 Billing Console - Credits 来查看折扣点数状态：`https://xxx`
> 
> 如果您有其他的问题，您可以点击以下链接，透过支持中心回复本工单，我们将诚挚提供协助：`https://xxx`
> 
> 祝您有个美好的一天！
> 
> 您的回馈是我们进步的动力，邀请您透过支持中心于回复的右上角给予星等评价。

***到此，老狗的退款算是有了着落，也感慨亚马逊的客服还是很好的。***

PS：给了客服全部五星好评，并且想起来上次腾讯云事故，申请补偿时客服答应给予无门槛代金券作为补偿，结果是空头支票，根本没有发放！！！垃圾腾讯，直接骗人是吧？！

## 老狗的评价

经过此次事件，老狗对亚马逊云做出以下两点评价：
1. 控制台操作太繁琐麻烦了！只适合长期使用的用户，因为长期使用很多功能大都能有一定的熟练度，对于偶尔用一下控制台的用户来说，操作亚马逊控制台简直是折磨。
2. 亚马逊的客服很Nice！

目前老狗使用过阿里云、腾讯云、亚马逊云、Vultr、搬瓦工这几个服务商的资源，除了搬瓦工可以说是没有控制台外，其他厂商都有功能齐全的控制台，个人觉得，腾讯云的控制台最好用！***BUT！腾讯的客服是真的垃圾。***

评价一波亚马逊云！一次意料之外的申请退款。

twitter:card

twitter:title

https://images.oldmoon.top/images/dingdangdog/oldmoon.png

twitter:image

努力做一只帅气、有才、豁达的老狗！

twitter:description