分类 默认分类 下的文章

===============window10中的配置和设置==============
启用smb共享服务
Windows默认关闭了samba服务,需要将其开启。
1.打开控制面板,选择“程序”进入
2.选择“启用或关闭Windows功能”进入
3.勾选“SMB 1.0/CIFS 文件共享支持”点击确定
4.电脑自动配置
5.等到配置完成,重启电脑

创建访问账号
打开控制面板,账户,添加一个本地用户账号(非microsoft账户)用于远程系统登录到本机来访问文件夹

网络设置
1.打开控制面板,选择“网络和Internet”进入
2.进入“查看网络状态和任务”
3.进入“更改高级共享设置”
4.根据需求修改其中的共享选项:
一般默认就行了

共享文件夹设置
右键需要共享的文件夹,属性-共享-高级共享设置-权限-用户和组->添加,在对象和名称输入框输入刚刚创建的用户名,点击【检查名称】 ,然后确定。
在共享权限列表中选择这个用户,然后设置访问权限,再确定,再确定高级共享。
微信图片_20210914104731.png
再在属性面板点击【共享】,选择框下拉,选择创建的账户,再设置权限级别,最后点击【共享】
微信图片_20210914104727.png

===============linux中的配置和设置==============
安装cifs文件系统(微软出的一个文件系统)

apt-get install cifs-utils
#或者
yum install cifs-utils

使用mount挂载远程目录

mkdir /mnt/window
mount -t cifs -o username=myuser,password=xxx,vers=1.0 //192.168.0.126/slim_share /mnt/window

#可读写挂载
mount -t cifs -o username=myuser,password=xxx,rw,file_mode=0777,dir_mode=0777 //192.168.1.95/web /www/web/

常见问题
查看日志tail /var/log/kern.log
1.最基本的错误——共享没放开权限
2.账户密码错误:属于比较常见的。最好查看一下win的用户,哪些是开启的哪些是禁用的,还需要特别注意“名称”和“全名”是不一样的,“全名”只是个昵称而已
3.没有写权限:共享文件夹放在C盘,对C盘的写是需要认证管理员权限的,所以尽量不要放到C盘
4.Remote IO Error:这个错误比较难排查,属于win系统错误,google上有一些解决方案,修改一下注册表参数就正常了

添加开机自动挂载
mount命令是手动挂载的,系统重启就没有挂载了,要想开机自动挂载,可以把挂载命令写到开机启动文件自动执行挂载,怎么添加到启动脚本,每种linux系统有可能不一样,自行查找方法吧,这里不多写了

错误信息如下 :

SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction

查看innodb状态:

show engine innodb status

结果:

------------------------

LATEST DETECTED DEADLOCK

------------------------

2017-01-04 09:25:17 7f553477d700

*** (1) TRANSACTION:

TRANSACTION 124378994, ACTIVE 0.007 sec starting index read

mysql tables in use 1, locked 1

LOCK WAIT 4 lock struct(s), heap size 1184, 8 row lock(s), undo log entries 7

LOCK BLOCKING MySQL thread id: 11573556 block 11572504

MySQL thread id 11572504, OS thread handle 0x7f56342fb700, query id 3368968901 10.44.182.0 shzfstore updating

UPDATE `sku` SET `quantity`=quantity-'1',`lock_stock`=lock_stock+'1',`sys_version`=sys_version+1 WHERE `id` = '15608' AND `quantity` >= '1' limit 1

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 393 page no 45 n bits 248 index `PRIMARY` of table `store_product`.`sku` trx id 124378994 lock_mode X locks rec but not gap waiting

Record lock, heap no 19 PHYSICAL RECORD: n_fields 19; compact format; info bits 0

......

*** (2) TRANSACTION:

TRANSACTION 124378995, ACTIVE 0.004 sec starting index read

mysql tables in use 1, locked 1

3 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1

MySQL thread id 11573556, OS thread handle 0x7f553477d700, query id 3368968902 10.172.221.117 shzfstore updating

UPDATE `sku` SET `quantity`=quantity-'1',`lock_stock`=lock_stock+'1',`sys_version`=sys_version+1 WHERE `id` = '15504' AND `quantity` >= '1' limit 1

*** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 393 page no 45 n bits 248 index `PRIMARY` of table `store_product`.`sku` trx id 124378995 lock_mode X locks rec but not gap

Record lock, heap no 19 PHYSICAL RECORD: n_fields 19; compact format; info bits 0

......

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 393 page no 43 n bits 240 index `PRIMARY` of table `store_product`.`sku` trx id 124378995 lock_mode X locks rec but not gap waiting

Record lock, heap no 81 PHYSICAL RECORD: n_fields 19; compact format; info bits 0

......

*** WE ROLL BACK TRANSACTION (2)

LATEST DETECTED DEADLOCK记录了最近一次的死锁情况。上面还可以看出两个事务之间发生锁竞争时,给我们留下的部分数据
事务1

UPDATEskuSETquantity=quantity-'1',lock_stock=lock_stock+'1',sys_version=sys_version+1 WHEREid= '15608' ANDquantity>= '1' limit 1

事务2

UPDATEskuSETquantity=quantity-'1',lock_stock=lock_stock+'1',sys_version=sys_version+1 WHEREid= '15504' ANDquantity>= '1' limit 1

死锁的两个资源均被lock_mode X locks了

最后,mysql给了很重要的一个数据“WE ROLL BACK TRANSACTION (2)” MYSQL回滚了事务2。既然mysql回滚了事务2,那么肯定是事务2的语句触发了死锁,被mysql回滚了,也就是应该为报错日志所记录的那部分。同时,MYSQL执行了事务1,那么事务1的SQL语句肯定被记录在BINLOG中了。

2.查看binlog日志,找出事务1所执行的语句
查找依据:

SQL语句,根据LATEST DETECTED DEADLOCK提供的死锁时记录的sql语句。
线程ID(mysql的唯一标识): MySQL thread id 11572504
执行时间(时间线):2017-01-04 09:25:17 7f553477d700
根据以上三个标识,以及BINLOG的起始标志“BEGIN、COMMIT”,几乎可以100%确定事务1所包含的SQL语句。

binlog信息大致如下

#170104  9:25:17 server id 3194178605  end_log_pos 137170469 CRC32 0x1b6559de   Query   thread_id=11572504  exec_time=0 error_code=0
SET TIMESTAMP=1483493117/*!*/;
BEGIN
......
### UPDATE `store_product`.`sku`
### WHERE
###   @1=15504
###   @2=11516
###   @3=0.01
###   @4=120065
###   @5=109433
###   @6=19
### SET
###   @1=15504
###   @2=11516
###   @3=0.01
###   @4=120065
###   @5=109432
###   @6=20
# at 137172557
......
### UPDATE `store_product`.`sku`
### WHERE
###   @1=15608
###   @2=11551
###   @3=0.01
###   @4=120077
###   @5=109426
###   @6=19
### SET
###   @1=15608
###   @2=11551
###   @3=0.01
###   @4=120077
###   @5=109425
###   @6=20
......
COMMIT/*!*/;

3.还原事务2所包含的执行语句
事务1的语句找齐了,接下来找事务2的语句,还记得我们开头提供的报错日志吗,那个日志里也详细记录了发起请求时的参数情况(截图未展示),根据参数和我们处理业务的代码,可以复现事务2所要执行的语句

BEGIN
......
### UPDATE `store_product`.`sku`
### WHERE
###   @1=15608
###   @2=11516
###   @3=0.01
###   @4=120065
###   @5=109433
###   @6=19
### SET
###   @1=15608
###   @2=11516
###   @3=0.01
###   @4=120065
###   @5=109432
###   @6=20
......
### UPDATE `store_product`.`sku`
### WHERE
###   @1=15504
###   @2=11551
###   @3=0.01
###   @4=120077
###   @5=109426
###   @6=19
### SET
###   @1=15504
###   @2=11551
###   @3=0.01
###   @4=120077
###   @5=109425
###   @6=20
......
COMMIT/*!*/;

根据两个事务所执行的sql语句,目前可以还原死锁产生的原因了

4.查看两个事务执行语句的顺序:

顺序    事务1    事务2    说明
1    begin        
2        begin    
3    update        事务1 给 sku表 id 15504记录上 X 锁
4        update    事务2 给 sku表 id 15608记录上 X 锁
5    update        这里是关键,事务1想给sku表 id 15608上X锁,发现被别人(事务2)上锁了,等待锁释放
6        update    事物2打算给sku表id为15504记录上 X 排它锁,发现被其他事务上了,而且此事务居然还在等他提交,这时MYSQL立刻回滚事务2…(php发现MYSQL返回死锁信息,记录该信息到错误日志…发送回滚指令…mysql已经“帮”他回滚了…)
7    执行成功        事务1发现别人的锁释放了,获得X锁,执行成功
8    commit        事务1执行成功,记录binlog日志

解决方案
减小事务中的语句数量
在业务中调整语句的执行顺序,例如可以按照where条件中字段的大小进行一下排序,按照排序后顺序执行,让死锁变为锁等待。
相关补充
innodb的行锁,锁的是查询条件中的索引字段,以及索引字段对应的primary key字段

本文转自:https://www.jianshu.com/p/6049b046e7b4,仅作学习参考

以下是摘自宝塔释放内存的脚本:

if [ -f "/etc/init.d/php-fpm-74" ];then
    /etc/init.d/php-fpm-74 reload
fi

if [ -f "/etc/init.d/mysqld" ];then
    /etc/init.d/mysqld reload
fi

if [ -f "/etc/init.d/nginx" ];then
    /etc/init.d/nginx reload
fi

if [ -f "/etc/init.d/httpd" ];then
    /etc/init.d/httpd graceful
fi

if [ -f "/etc/init.d/pure-ftpd" ];then
    pkill -9 pure-ftpd
    sleep 0.3
    /etc/init.d/pure-ftpd start 2>/dev/null
fi

sync
sleep 2
sync
echo 3 > /proc/sys/vm/drop_caches

sync 命令:sync 指令会将存于 buffer 中的资料强制写入硬盘中
Linux 系统中欲写入硬盘的资料有的时候为了效率起见,会写到 filesystem buffer 中,这个 buffer 是一块记忆体空间,如果欲写入硬盘的资料存于此 buffer 中,而系统又突然断电的话,那么资料就会流失了。

/proc/sys/vm/drop_caches的值,默认为0
来自官方的解释:

/proc/sys/vm/drop_caches (since Linux 2.6.16)
Writing to this file causes the kernel to drop clean caches,
dentries and inodes from memory, causing that memory to become
free.

To free pagecache, use echo 1 > /proc/sys/vm/drop_caches; to
free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches;
to free pagecache, dentries and inodes, use echo 3 >
/proc/sys/vm/drop_caches.

Because this is a non-destructive operation and dirty objects
are not freeable, the user should run sync first.

写入此文件会导致内核丢弃内存中的 dentry 和 inode缓存的数据,导致内存被释放。
释放页面缓存,请使用

echo 1 > /proc/sys/vm/drop_caches

释放 dentries 和 inode,使用

echo 2 > /proc/sys/vm/drop_caches

释放 pagecache、dentries 和 inode,请使用

echo 3 > /proc/sys/vm/drop_caches

使用前,请执行sync命令,将 buffer 中的数据写入磁盘

什么是vulhub?
Vulhub是一个基于docker和docker-compose的漏洞环境集,进入对应目录并执行一条语句即可启动一个全新的漏洞环境,让漏洞复现变得更加简单,让安全研究者更加专注于漏洞原理本身。Vulhub的官方地址为 www.vulhub.org。

我在今天搭建靶场的时候遇到了几个问题:

系统时间问题。
kali安装docker的时候需要证书。
kali源修改后,显示的签名错误(参考1修改时间即可)。
docker安装pip,compose。
kali在虚拟机状态下不能自己拉伸屏幕。
如何更新docker源
一.系统时间问题:
先更新系统时间

二 、 安装docker
因为Vulhub是一个基于docker和docker-compose的漏洞环境集。

安装https协议、CA证书

apt-get install -y apt-transport-https ca-certificates

安装docker

apt install docker.io

查看版本,是否安装成功。

docker -v

显示docker运行状态

docker  ps 

暂时未运行所以是空的。

安装pip

apt-get install python3-pip

安装docker-compose

pip3 install docker-compose

查看docker-compose版本

docker-compose -v

git vulhub
git clone https://github.com/vulhub/vulhub.git

下载成功后,进入到vulhub目录( cd vulhub ),通过 ls 命令查看漏洞靶场。

下面,随便进入一个目录,

cd  /vulhub/weblogic/CVE-2018-2628

启动环境

docker-compose build //可选
docker-compose up -d //自动生成漏洞环境

查看启动环境,发现端口是7001

docker-compose ps

docker-compose会默认根据当前目录下的配置文件启动容器,在关闭及移除环境的时候,也需要在对应目录下。我们执行docker-compose up -d后,不要离开当前目录即可,漏洞测试结束后,执行如下命令移除环境:

docker-compose down

三、安装open-vm-tool

apt-get install open-vm-tools-desktop fuse

四、更新docker源
阿里云: https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors

安装/升级Docker客户端 推荐安装1.10.0以上版本的Docker客户端,参考文档 docker-ce
配置镜像加速器 针对Docker客户端版本大于 1.10.0 的用户
下面的https://xxx.mirror.aliyuncs.com,其中的XXX是我的用户名,为了隐私 我设置成了xxx,你们要用自己的哦。
您可以通过修改daemon配置文件/etc/docker/daemon.json来使用加速器

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": ["https://xxx.mirror.aliyuncs.com"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker