以太坊挖矿介绍

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

新的技术分享站点

新的技术分享站点

服务器维护

阿里云优惠! 欢迎大家领取,谢谢支持!
阿里云优惠

 

 

 

 

 

阿里云618大促!

阿里云限量红包!

 

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 出现新变种,杀伤力更强。

安全团队 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 脚本攻击负载植入在一个用于“电子安全、集成和报警监控”业务的网站上。

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

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

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

Chrome 将警告用户不再支持 Flash Player

Adobe 计划在 2020 年淘汰 Flash Player,这将是万维网历史上的一个关键点。全世界都在为这个关键时刻做准备,其中就包括浏览器开发公司。谷歌正在尽可能顺利地完成 Flash Player 的过渡,即将推出的 Chrome 76 也将在这方面迈出这关键的一步

新版本浏览器将完全禁用 Flash Player,但谷歌希望启用此功能的用户亲自在设置中完成所有操作。浏览器明显的变化是启动时显示的警告,不过谷歌可能在未来的几周对这个显示做进一步的调整。

据 9to5google 报告,最近 Chromium 的开发人员在讨论中提供了显示警告的早期视图,该警告将在浏览器顶部作为信息栏显示。“2020年12月之后 Flash Player 将不再受支持”,通知中写道,并在末尾附上了链接,方便用户了解通知详情。

目前,Canary 版 Google Chrome 尚未加入此警告。据 Chromium 的代码提交,警告的显示已在进行中,晚些将与功能标志一起添加到新版浏览器。

Chrome 即将加入的这个警告显示,可以让用户提前得知 Flash Player 支持的即将结束,使得浏览器取消支持 Flash Player 的整个转换过程更加顺畅。

apollo配置中心新增自定义环境

Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。   默认阿波罗环境设定了

LOCAL, DEV, FWS, FAT, UAT, LPT, PRO, TOOLS, UNKNOWN;这样的环境命名空间。
增加sklinux环境示范:
1.假设增加sklinux
在com.ctrip.framework.apollo.core.enums.Env类中有定义。比如增加sklinux环境L
public enum Env{
  LOCAL, DEV, SKLINUX, FWS, FAT, UAT, LPT, PRO, TOOLS, UNKNOWN;
  ...
}
apollo/apollo-core/src/main/java/com/ctrip/framework/apollo/core/enums/Env.java 文件路径

2.修改com.ctrip.framework.apollo.core.enums.EnvUtils类,在其中加入BETA枚举的转换逻辑
case "SKLINUX":
        return Env.SKLINUX;

文件路径:
apollo/apollo-core/src/main/java/com/ctrip/framework/apollo/core/enums/EnvUtils.java
3.修改apollo-env.properties,增加beta.meta占位符:
local.meta=http://localhost:8080
dev.meta=${dev_meta}
fat.meta=${fat_meta}
sklinux.meta=${sklinux_meta}
uat.meta=${uat_meta}
lpt.meta=${lpt_meta}
pro.meta=${pro_meta}
文件路径:
apollo/apollo-portal/src/main/resources/apollo-env.properties
4.修改com.ctrip.framework.apollo.core.internals.LegacyMetaServerProvider类,增加读取SKLINUX环境的meta server地址逻辑:

增加

env.getProperty("sklinux_meta", prop.getProperty("sklinux.meta")));

未增加前:
 domains.put(Env.LOCAL, getMetaServerAddress(prop, "local_meta", "local.meta"));
 domains.put(Env.DEV, getMetaServerAddress(prop, "dev_meta", "dev.meta"));
 domains.put(Env.FAT, getMetaServerAddress(prop, "fat_meta", "fat.meta"));
 domains.put(Env.UAT, getMetaServerAddress(prop, "uat_meta", "uat.meta"));
 domains.put(Env.LPT, getMetaServerAddress(prop, "lpt_meta", "lpt.meta"));
 domains.put(Env.PRO, getMetaServerAddress(prop, "pro_meta", "pro.meta"));
文件路径:
./apollo/apollo-core/src/main/java/com/ctrip/framework/apollo/core/internals/LegacyMetaServerProvider.java
cd apollo/scripts/ && ./build.sh 即可

[INFO] Reactor Summary for Apollo 1.4.0-SNAPSHOT:
[INFO]
[INFO] Apollo ……………………………………… SUCCESS [ 0.667 s]
[INFO] Apollo Core …………………………………. SUCCESS [ 3.964 s]
[INFO] Apollo Common ……………………………….. SUCCESS [ 1.377 s]
[INFO] Apollo Open Api ……………………………… SUCCESS [ 0.875 s]
[INFO] Apollo Portal ……………………………….. SUCCESS [ 6.668 s]
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 14.254 s
[INFO] Finished at: 2019-05-06T10:50:55+08:00
[INFO] ————————————————————————
==== building portal finished ====

5.protaldb增加SKLINUX环境配置。portaldb.serverconfig 表中的apollo.portal.envs字段 dev,uat,fat,pro,sklinux

6.为apollo-portal添加新增环境对应的meta server地址。apollo-env.properties中增加:dev.meta=http://x.x.x.x:8080
7.准备sklinux环境的adminservice和configservice 以及db,然后启动
8.重启portal服务就新增成功了。