作者归档:SK

关于SK

服务器维护 服务器配置 服务器 维护 运维 网管 系统调优 网络调优 数据库优化

阿里云ecs在线不停机扩展硬盘

1.选择ecs的磁盘,选择在线扩容-扩容大小-付费

2.安装相应工具
centos系列

yum install cloud-utils-growpart
yum install xfsprogs

ubuntu、debian系列:

apt install cloud-guest-utils
apt install xfsprogs

下面示范将vda设备的第一个分区扩容

3.扩展a步骤
growpart /dev/vda 1

4.扩展b步骤
resize2fs /dev/vda1

详细过程:

fdisk -l命令查看现有云盘大小

此处以CentOS 7操作系统为例演示分区扩展的步骤。

运行fdisk -l命令查看现有云盘大小。
以下示例返回云盘(/dev/vda)容量是100GiB。
[root@ecshost ~]# fdisk -l
Disk /dev/vda: 107.4 GB, 107374182400 bytes, 209715200 sectors
省略

运行df -h命令查看云盘分区大小。
以下示例返回分区(/dev/vda1)容量是20GiB。
[root@ecshost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 1.5G 18G 8% /
显示20G

运行growpart <DeviceName> <PartionNumber>命令调用growpart为需要扩容的云盘和对应的第几个分区扩容。

示例命令表示为系统盘的第一个分区扩容。

[root@ecshost ~]# growpart /dev/vda 1

CHANGED: partition=1 start=2048 old: size=41940992 end=41943040 new: size=209710462,end=209712510

若运行命令后报以下错误,您可以运行LANG=en_US.UTF-8切换ECS实例的字符编码类型。

[root@ecshost ~]# growpart /dev/vda 1
unexpected output in sfdisk –version [sfdisk,来自 util-linux 2.23.2]

[root@ecshost ~]# LANG=en_US.UTF-8
运行resize2fs <PartitionName>命令调用resize2fs扩容文件系统。

示例命令表示为扩容系统盘的/dev/vda1分区文件系统。

[root@ecshost ~]# resize2fs /dev/vda1
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 7
The filesystem on /dev/vda1 is now 26213807 blocks long.
说明 如果您使用的是xfs文件系统,运行xfs_growfs /dev/vda1命令扩容文件系统。
运行df -h命令查看云盘分区大小。
返回分区(/dev/vda1)容量是100GiB,表示已经成功扩容。

[root@ecshost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 99G 1.6G 93G 2% /

supervisor守护服务遇见的几个坑

近期在ubunt系列服务器上遇见了supervisor的几个坑,所以将服务守护都已经切换到systemd。

坑一、资源限制配额不跟随limits.conf

1.我们在用supervisor守护一个服务A的时候,发现由supervisor拉起的服务文件描述符未跟随系统limits设置。

[program:servicea]
username=root
command = bash /etc/servicea.sh
autostart = true
stopasgroup = true
autorestart = true
startsecs = 3
stdout_logfile = /var/log/servicea.log

cat /proc/$(ps ax|grep servicea|grep -v grep|awk {print $1})/limits |grep open
Max open files            1024                 4096                 files


发现最大的文件描述符还是1024,对于系统初始化优化的时候,我们都会更改/etc/security/limits.conf

root  soft   nofile  65535
root  hard   nofile  65535
root  soft   nproc    65535
root  hard   nproc    65535
* soft   nproc    65535
* hard   nproc    65535
* soft   nofile  65535
* hard   nofile  65535
root@sklinux.com:~# ulimit -SHn
65535

或者比上诉值更大,然而supervisor守护服务,资源限制配额不跟随limits.conf。

坑二、supervisor守护prometheus服务的时候吃掉重要参数

2.我们在用supervisor守护prometheus服务的时候发现,重要参数被“吃”掉。

supervisor中prometeus配置如下:

#为方便查看做了换行处理
[program:prometheus]
username=root
directory=/opt/prometheus/data
command = /opt/prometheus/prometheus 
--config.file=/opt/prometheus/prometheus.yml
--web.listen-address="8.8.8.8:9090" 
--storage.tsdb.path="/opt/prometheus/data/"
--storage.tsdb.retention.time=90d --web.enable-lifecycle 
autostart = flase
stopasgroup = true
autorestart = true
startsecs = 3
stdout_logfile = /var/log/prometheus.log

我们发现每次拉起服务的时候,–storage.tsdb.path=“/opt/prometheus/data/“参数未生效,数据始终默认保存在/data下。 然后通过

command = /start.prometheus.sh


start.prometheus.sh 内容:
#为方便查看做了换行处理
/opt/prometheus/prometheus 
--config.file=/opt/prometheus/prometheus.yml
--web.listen-address="8.8.8.8:9090"
--storage.tsdb.path="/opt/prometheus/data/"
--storage.tsdb.retention.time=90d --web.enable-lifecycle

同样,参数无效。但是通过手工执行/start.prometheus.sh 可以将数据存储路径存在目标路径/opt/prometheus/data/中。
后来,我们将上诉服务切换为systemd守护,一切ok了! 比较:

Systemd

a.稳定可靠
b.支持 Before/After 依赖机制 c.支持 Notify 机制
d.支持基于 cgroup 的资源限制

Supervisord

a.支持通过 priority 配置进程启动顺序
b.日志友好方便查阅
c.跨平台使用
d.扩展开发友好,守护业务系统
e.但是bug多,资源限制不足

以太坊挖矿介绍

以太坊挖矿是一个涉及高度计算的工作,需要大量的时间和处理能力,期间会消耗大量的电力。
其主要算法是Ethash。

矿工通过以区块链技术为数学难题提供解决方案来获得奖励,就像比特币挖矿一样。以太坊是第一个“世界计算机”。这是一个分布式网络,任何人都可以使用。它能够运行应用程序,不存在停机、审查或欺诈的可能性。 继续阅读

ubuntu关闭内核自动更新

ubuntu server和desktop版本都默认启动了,自动更新内核的操作。这对于生产环境来说是不友好的。因为新的内核可能引入新的安全问题、不稳定因素。

默认开启了内核自动更新所以我们关闭自动内核更新。
执行:

sudo apt-mark hold linux-image-generic linux-headers-generic

如果要重新启用内核更新:

sudo apt-mark unhold linux-image-generic linux-headers-generic

卸载内核 注意:不要先盲目地卸载内核,起码要安装一个新的才可以卸载

查看内核安装情况:

dpkg --list | grep linux-image
dpkg --list | grep linux-headers
卸载内核:

sudo ap purge linux-image-xx
sudo apt purge linux-headers-xx
sudo apt autoremove
在上述操作都完成之后,执行sudo update-grub更新grub

istio服务网格生产环境ingress网关部署SSL实战

服务网格实战之SSL服务发布

准备物件:
1.被各大厂认证签发过的、认证的域名私有证书、私钥,比如istio.sklinux.com。
2.基于云的k8s集群(生产环境)。
3.istio基础设施已经通过helm部署,并$(kubectl get svc -n istio-system|grep istio-ingressgateway)得到外部ip。
4.创建证书对象以及服务应用编排。
5.发布应用编排并使用https://istio.sklinux.com 进行测试。
大致步骤分为上面5部分,下面重点说下第4部分
首先创建证书对象:
kubectl create -n istio-system secret tls istio-ingressgateway-certs \
–key ssl/istio.sklinux.com/private.key \
–cert ssl/istio.sklinux.com/certificate.crt
将在istio-system创建一个secret为istio-ingressgateway-certs的对象,分别是私钥和证书。
然后进行检查是否在ingress-gateway的容器中已经发现:

~ kubectl exec -it istio-ingressgateway-xxxxx-xxxxx -n istio-system -c istio-proxy — ls -al /etc/istio/ingressgateway-certs/
total 0
lrwxrwxrwx 1 root root 14 May 27 09:33 tls.crt -> ..data/tls.crt
lrwxrwxrwx 1 root root 14 May 27 09:33 tls.key -> ..data/tls.key

已经看见tls.crt和tls.key

下面进行服务编排:
主要编排路线是:
Gateway->VirtualService->DestinationRule->Service->Deployment
其中在Gateway中定义协议为HTTPS以及域名:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
hosts:
- istio.sklinux.com
VirtualService 主要是做一些http的匹配规则,然后匹配规则流向何处,比如流向DestinationRule中的哪个版本。
DestinationRule中主要定义了有哪些目标路由和版本,这些目标具体由Service定义。版本的标签是由多个标签组成的deployment构成。

编排好后使用

istioctl kube-inject -f注入yaml,然后kubectl create -f 即可!

istio-ingress-sds的一些障碍绕行方法

 

1.通过官网的by step 使用ingress-gateway发布ssl始终不成功,但是ingress-gateway的http服务暴露ok。

2.决定使用曲线救援方法,在外侧通过nginx来发布tls,内部回源使用http,但是遇见了http 426的错误。

➜ ~ curl https://192.168.1.25:443/ -H “Host: uat.sklinux.com” -i -k -v
* Trying 192.168.1.25…
* TCP_NODELAY set
* Connected to 192.168.1.25 (192.168.1.25) port 443 (#0)
* WARNING: disabling hostname validation also disables SNI.
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.uat.sklinux.com
* Server certificate: Fishdrowned ROOT CA
> GET / HTTP/1.1
> Host: uat.sklinux.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 426 Upgrade Required
HTTP/1.1 426 Upgrade Required
< Server: nginx
Server: nginx
< Date: Mon, 27 May 2019 02:25:25 GMT
Date: Mon, 27 May 2019 02:25:25 GMT
< Content-Length: 0
Content-Length: 0
< Connection: keep-alive
Connection: keep-alive

经查原因为:

nginx 反向代理默认走的http 1.0版本

但是 被反向代理的服务器是1.1版本的!

所以在反向代理的时候加上一句:proxy_http_version 1.1;

即可!

但是最终通过SDS进行tls服务发布还没彻底解决,这个问题将持续跟进社区。

kubernetes-1.14安装

1.所有节点安装docker、kubelet、kubeadm、kubectl

curl -fsSL https://get.docker.com | bash -s docker –mirror Aliyun
curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | apt-key add -
cat << EOF > /etc/apt/sources.list.d/kubernetes.list
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
EOF
apt-get update
apt-get install -y kubelet kubeadm kubectl

2.在master和node节点拉取海外docker镜像

kubeadm config images list列出所需要img:

k8s.gcr.io/kube-apiserver:v1.14.0
k8s.gcr.io/kube-controller-manager:v1.14.0
k8s.gcr.io/kube-scheduler:v1.14.0
k8s.gcr.io/kube-proxy:v1.14.0
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.3.10
k8s.gcr.io/coredns:1.3.1

3.master上初始化

kubeadm init

初始化成功后你会看见如下提示
Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run “kubectl apply -f [podnetwork].yaml” with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.0.20:6443 –token 8sio7q.g6cj9m15c0ev3d9b \
–discovery-token-ca-cert-hash sha256:81fc89c762536cadc9580278bd12fe14933ead5d9bdf5b5b1a9c07f0a3084958

4.node加入集群

kubeadm join 192.168.0.20:6443 –token 8sio7q.g6cj9m15c0ev3d9b \
–discovery-token-ca-cert-hash sha256:81fc89c762536cadc9580278bd12fe14933ead5d9bdf5b5b1a9c07f0a3084958

即可

5.coredns可能运行有问题,是因为网络还不是覆盖网络

需要安装

https://docs.projectcalico.org/v3.6/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml

修改里面cidr方面的参数然后创建应用 @master上

6.安装完成

NAME STATUS ROLES AGE VERSION
node20 Ready master 9d v1.14.0
node21 Ready <none> 9d v1.14.0
node22 Ready <none> 7d22h v1.14.0

 

aws-vpc简介

Amazon VPC (Virtual Private Cloud) 是AWS的网络基础设施。使用VPC服务可以在AWS中创建一个独立隔离的网络,在这个隔离的网络空间中可以创建任何AWS资源,例如EC2、Redis、RDS数据库等等,VPC网络使这些AWS资源互相连接,传递数据,并且提供外网访问的网关。

VPC和子网(Subnet)

当新建一个VPC,需要为虚拟网络定义IP地址范围作为CIDR地址,例如CIDR为10.1.0.0/16。IPv4的CIDR可以手动指定,但是IPv6的CIDR只能由AWS自动分配。

CIDR(无类别域间路由,Classless Inter-Domain Routing)将IP地址按照前缀分成一组,使用一种无类别的域际路由选择算法,大大减少了路由表维护的条目数。

VPC的IP地址段可以进一步划分IP段,从而创建子网(Subnet)。一个VPC横跨多个可用区(Availability Zone),但是一个子网只能位于一个可用区里面。 继续阅读

僵尸网络 Mirai 新变种来袭,企业成新目标

臭名昭著的 IoT/Linux 僵尸网络 Mirai 出现新变种,杀伤力更强。

服务器维护、云运维、专业Linux服务器维护、Linux服务器搭建、qq33615066 服务器维护、云运维、专业Linux服务器维护、Linux服务器搭建、qq33615066

安全团队 Unit 42 近日发布报告披露了 Mirai 的新变种病毒,研究者在样本中发现了该病毒的 27 种漏洞利用方式,其中 11 种是 Mirai 中没遇到过的。

Mirai 是去年肆虐的僵尸网络病毒,其通过感染存在漏洞的 IoT 设备,并下载 Telnet 扫描其它潜在 Mirai 僵尸宿主机,将其感染,连结成网,在需要时对目标系统发起攻击。Mirai 先后进行 DDoS 导致了美国的、德国大断网,并针对全球最大动态 DNS 提供商 DYN 与网络托管服务提供商 OVH 等进行攻击,带来了极其恶劣的影响。

同时 Mirai 作者将其源码公布,这使得更多人可以更加方便地对该病毒进行变种创作,此次发现的新变种正是其中之一。

Unit 42 安全人员指出,此次新变种针对不同嵌入式设备,如路由器、网络存储设备与网络摄像机等,利用这些设备存在的漏洞进行大面积攻击。报告中特别指出,该变种僵尸网络会针对 WePresent WiPG-1000 无线演示系统和 LG Supersign 电视,这两款设备都是企业级产品,并且它们存在的漏洞早在去年就公开了。

报告认为这表明该变种有将 Mirai 攻击从公共基础设施转向企业目标的趋势。

研究人员表示目前该变种僵尸网络还在通过不断感染更多设备,并添加更多用于对设备进行暴力破解的密码扩大其攻击面,而利用企业应用漏洞使得攻击具有更大的网络带宽,DDoS 能力大大提高。

此外,该变种还有其它特性,比如它使用与 Mirai 特征相同的加密方案,表密钥为 0xbeafdead;它使用域 epicrustserver[.]cf 在端口 3933 进行 C2 通信;除了扫描其它易受感染的设备,它还可以进行 HTTP Flood DDoS 攻击。

报告中还提到了一个具有讽刺意味的案例,该变种病毒的 shell 脚本攻击负载植入在一个用于“电子安全、集成和报警监控”业务的网站上。

服务器维护、云运维、专业Linux服务器维护、Linux服务器搭建、qq33615066 服务器维护、云运维、专业Linux服务器维护、Linux服务器搭建、qq33615066

那么,如此疯狂的僵尸网络冲着企业而来,企业可以怎么办呢?

  • 了解网络上的 IoT 设备、更换默认密码,确保设备更新补丁
  • 无法修补的设备直接从网络中去掉

详情查看报告:https://unit42.paloaltonetworks.com/new-mirai-variant-targets-enterprise-wireless-presentation-display-systems