minlearn2016
TA的个人档案
minlearn2016_个人页
文章
143
问答
162
视频
0
个人介绍
https://gitee.com/minlearn/minlearnprogramming/：minlearn的一云多端云OS/统一编程栈方案。
擅长的技术
- Linux
- 数据库
获得更多能力
通用技术能力：
-
Linux
初级
能力说明：
掌握计算机基础知识，初步了解Linux系统特性、安装步骤以及基本命令和操作；具备计算机基础网络知识与数据通信基础知识。
云产品技术能力：
暂时未有相关云产品技术能力~
阿里云技能认证
详细说明-
发表了文章 2020-10-27
panel.sh：一个nginx+docker的云函和在线IDE面板,发明你自己的paas(1)
本文关键字：Cannot connect to the Docker daemon at，containerd cannot properly do "clean-up" with shim process during start up，用标准方法实现的类群晖paas，with debugable appliance inside built 在前面《利用openfaas faasd在你的云主机上部署function serverless面板》中我们介绍了用从https://github.com/openfaas/faasd/tree/0.9.2/cloud-config.txt提取的脚本安装openfaas（后来我们用上了0.9.5），和在云主机上使用它的方法，见《在openfaas面板上安装onemanager1，2》，如果说这3文定位主要是基本安装，排错，和调试，那么本文开始就着重于增强和提高脚本的体验了。前3文的成果和努力依旧有效。 第一个问题，脚本要能在一台干净的ubuntu1804的机器上安装，尽量一次成功，如果不能成功，那么它也要求能多次覆盖安装不致于弄坏系统。这就要求脚本中安装的组件分开，各组件包括其配置要standalone方式放置，这样可以重装时拔插和替换，覆盖。 第二个问题，虽然我前3文中从来没遇到过，但是后来的尝试中，我发现在ubuntu1804同样的安装方式和组件版本（v1.3.3containerd+cni0.4.0+cniplugins0.8.5+faasd0.9.5），居然gateway那个container开启一会之后就会停止，导致8080根本不能访问。 不废话了，直接上新的脚本： 前置 更新了安装说明。集中化了全局变量，注意deps prepare部分，bridge-utils是为了控制cni制造的那个openfaas0虚拟网卡用。安装docker.io，是ubuntu上它可以同时安装containerd1.3.3和runc 从Docker 1.11开始，Docker容器运行已经不是简单的通过Docker daemon来启动，而是集成了containerd、runC等多个组件。如果去搜索一番，就会发现：docker-containerd 就是 containerd，而 docker-runc 就是 runc。containerd是真正管控容器的daemon，执行容器的时候用的是runc。为什么 要分的七零八散呢？为了防止docker一家独大,docker当年的实现被拆分出了几个标准化的模块,,标准化的目的是模块是可被其他实现替换的,其实也是为了实现类llvm的组件化可开发效果(软件抽象上，源头如果有分才能合，如果一开始就是合的就难分)。也是为了分布式效果。docker也像git一样做分布式部件化了，分布式就是设置2个部件，cliserver，这样在本地和远程都可这样架构。 而为什么是dockerio而不是docker-ce:事实是我还发现，有些系统上，安装了docker-ce再安装containerd。会导致系统出问题Cannot connect to the Docker daemon at 。docker与containerd不兼容，所以只好安装ubuntu维护的docker.io这种解决了containerd依赖的，它默认依赖containerd和runc(不过稍后我们会提到替换升级containerd的版本)。我们选用加入了最新cn ubuntu deb src后apt-get update得到的sudo apt install docker.io=19.03.6-0ubuntu1~18.04.1，sudo apt-cache madison docker.io出来的版本. #!/bin/bash ## currently tested under ubuntu1804 64b,easy to be ported to centos(can be tested with replacing apt-get and /etc/systemd/system) ## How to use this script in a cloudhost ## su root and then: ./panel.sh -d 'your domain to be binded' -m 'email you use to pass to certbot' -p 'your inital passwords'(email and passwords are not neccessary,feed email only if you encount the "toomanyrequestofagivetype" error) ## (no prefix https/http needed,should bind to the right ip ahead for laster certbot working) export DOMAIN_NAME='' export EMAIL_NAME='some@some.com' export PANEL_TYPE='0' export PASS_INIT='5cTWUsD75ZgL3VJHdzpHLfcvJyOrUnza1jr6KXry5pXUUNmGtqmCZU4yGoc9yW4' MIRROR_PATH="http://default-8g95m46n2bd18f80.service.tcloudbase.com/d/demos" # the pai backend SERVER_PATH=${MIRROR_PATH}/pai/pai-agent/stable/pai_agent_framework PAI_MATE_SERVER_PATH=${MIRROR_PATH}/pai/pai-mate/stable/install # the openfaas backend OPENFAAS_PATH=${MIRROR_PATH}/faasd # the code-server web ide CODE_SERVER_PATH=${MIRROR_PATH}/codeserver #install dir INSTALL_DIR="/root/.local" CONFIG_DIR="/root/.config" # datadir only for pai and common data DATA_DIR="/data" while [[ $# -ge 1 ]]; do case $1 in -d|--domain) shift DOMAIN_NAME="$1" shift ;; -m|--mail) shift EMAIL_NAME="$1" shift ;; -t|--paneltype) shift PANEL_TYPE="$1" shift ;; -p|--passinit) shift PASS_INIT="$1" shift ;; *) if [[ "$1" != 'error' ]]; then echo -ne "\nInvaild option: '$1'\n\n"; fi echo -ne " Usage(args are self explained):\n\tbash $(basename $0)\t-d/--domain\n\t\t\t\t\-m/--mail\n\t\t\t\t\-t/--paneltype\n\t\t\t\t-p/--passinit\n\t\t\t\t\n" exit 1; ;; esac done [[ "$EUID" -ne '0' ]] && echo "Error:This script must be run as root!" && exit 1; beginTime=$(date +%s) # write log with time writeProgressLog() { echo "[`date '+%Y-%m-%d %H:%M:%S'`][$1][$2]" echo "[`date '+%Y-%m-%d %H:%M:%S'`][$1][$2]" >> ${DATA_DIR}/h5/access.log } # update install progress updateProgress() { progress=$1 message=$2 status=$3 installType=$4 # echo "=====================$installType progress=======================" echo "=======================$installType progress=======================" >> ${DATA_DIR}/h5/access.log writeProgressLog "installType" $installType writeProgressLog "progress" $progress writeProgressLog "status" $status echo $message >> ${DATA_DIR}/h5/access.log if [ $status == "0" ]; then code=0 message="success" else code=1 message="$installType error" # exit 1 fi cat << EOF > ${DATA_DIR}/h5/progress.json { "code": $code, "message": "$message", "data": { "installType": "$installType", "progress": $progress } } EOF if [ $status == "0" ]; then code=0 message="success" else code=1 message="$installType error" # exit 1 fi if [ $status != "0" ]; then echo $message >> ${DATA_DIR}/h5/installErr.log fi } echo "=====================begin .....=====================" echo "PANEL_TYPE: ${PANEL_TYPE}" echo "DOMAIN_NAME: ${DOMAIN_NAME}" echo "SERVER_PATH: ${MIRROR_PATH}" echo "OPENFAAS_PATH: ${OPENFAAS_PATH}" echo "PAI_MATE_SERVER_PATH: ${PAI_MATE_SERVER_PATH}" echo "CODE_SERVER_PATH: ${CODE_SERVER_PATH}" echo "INSTALL_DIR: ${INSTALL_DIR}" rm -rf ${DATA_DIR}/h5 mkdir -p ${DATA_DIR}/h5 rm -rf ${DATA_DIR}/h5/index.json rm -rf ${DATA_DIR}/logs mkdir -p ${DATA_DIR}/logs mkdir -p ${INSTALL_DIR}/bin mkdir -p ${CONFIG_DIR} echo "=====================deps prepare progress(this may take long...)=======================" msg=$( #begin if [ $PANEL_TYPE == "0" ]; then apt-key adv --recv-keys --keyserver keyserver.Ubuntu.com 3B4FE6ACC0B21F32 echo deb http://cn.archive.ubuntu.com/ubuntu/ bionic main restricted universe multiverse >> /etc/apt/sources.list echo deb http://cn.archive.ubuntu.com/ubuntu/ bionic-security main restricted universe multiverse >> /etc/apt/sources.list echo deb http://cn.archive.ubuntu.com/ubuntu/ bionic-updates main restricted universe multiverse >> /etc/apt/sources.list echo deb http://cn.archive.ubuntu.com/ubuntu/ bionic-proposed main restricted universe multiverse >> /etc/apt/sources.list echo deb http://cn.archive.ubuntu.com/ubuntu/ bionic-backports main restricted universe multiverse >> /etc/apt/sources.list apt-get update apt-get install docker.io=19.03.6-0ubuntu1~18.04.1 --no-install-recommends bridge-utils -y apt-get install nginx python git python-certbot-nginx -y # sed '1{:a;N;5!b a};$d;N;P;D' -i /etc/apt/sources.list # apt-get update else apt-get update && apt-get install git nginx gcc python3.6 python3-pip python3-virtualenv python-certbot-nginx golang -y fi 2>&1) status=$? updateProgress 30 "$msg" "$status" "deps prepare" 基础组件代码:nginx front and docker backend 这部分虽然写死了各条转发。但重点在于如何根据具体的转发需要布置代码。这里的理论在于：如果代理服务器地址（proxy_pass后面那个）中是带有URI的，此URI会替换掉 location 所匹配的URI部分。 而如果代理服务器地址中是不带有URI的，则会用完整的请求URL来转发到代理服务器。 confignginx() { echo "=====================certbot renew+start+init progress=======================" systemctl enable nginx.service systemctl start nginx #cp -f /lib/systemd/system/certbot.service /etc/systemd/system/certbot-renew.service #echo '[Install]' >> /etc/systemd/system/certbot-renew.service #echo 'WantedBy=multi-user.target' >> /etc/systemd/system/certbot-renew.service #cp -f /lib/systemd/system/certbot.timer /etc/systemd/system/certbot-renew.timer # sed -i "s/renew/renew --nginx/g" /etc/systemd/system/certbot-renew.service rm -rf /etc/systemd/system/certbot-renew.service cat << 'EOF' > /etc/systemd/system/certbot-renew.service [Unit] Description=Certbot Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html Documentation=https://letsencrypt.readthedocs.io/en/latest/ [Service] Type=oneshot ExecStart=/usr/bin/certbot -q renew PrivateTmp=true [Install] WantedBy=multi-user.target EOF rm -rf /etc/systemd/system/certbot-renew.timer cat << 'EOF' > /etc/systemd/system/certbot-renew.timer [Unit] Description=Run certbot twice daily [Timer] OnCalendar=*-*-* 00,12:00:00 RandomizedDelaySec=43200 Persistent=true [Install] WantedBy=timers.target EOF msg=$( #first time renew certbot certonly --quiet --standalone --agree-tos --non-interactive -m ${EMAIL_NAME} -d ${DOMAIN_NAME} --pre-hook "systemctl stop nginx" systemctl daemon-reload systemctl enable certbot-renew.service systemctl start certbot-renew.service systemctl start certbot-renrew.timer 2>&1) status=$? updateProgress 40 "$msg" "$status" "certbot renew+start+init" echo "=====================nginx reconfig progress=======================" # add nginx conf rm -rf /etc/nginx/conf.d/default.conf cat << 'EOF' > /etc/nginx/conf.d/default.conf server { listen 443 http2 ssl; listen [::]:443 http2 ssl; server_name DOMAIN_NAME; ssl on; ssl_certificate /etc/letsencrypt/live/DOMAIN_NAME/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/DOMAIN_NAME/privkey.pem; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE; ssl_prefer_server_ciphers on; location / { proxy_pass http://localhost:PORT; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; } location /pai/ { proxy_pass http://localhost:5523; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; } location /faasd/ { proxy_pass http://localhost:8080/ui/; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; } location /codeserver/ { proxy_pass http://localhost:5000/; proxy_redirect http:// https://; proxy_set_header Host $host:443/codeserver; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; } } server { listen 80; server_name DOMAIN_NAME; if ($host = DOMAIN_NAME) { return 301 https://$host$request_uri; } return 404; } EOF sed -i "s#DOMAIN_NAME#${DOMAIN_NAME}#g" /etc/nginx/conf.d/default.conf if [ $PANEL_TYPE == "0" ]; then sed -i "s#PORT#8080/functions/#g" /etc/nginx/conf.d/default.conf else sed -i "s#PORT#3000#g" /etc/nginx/conf.d/default.conf fi # restart nginx msg=$( #begin [[ $(systemctl is-active nginx.service) == "activating" ]] && systemctl reload nginx.service systemctl restart nginx 2>&1) status=$? updateProgress 50 "$msg" "$status" "nginx reconfig" } confignginx 为了让docker能覆盖安装，接下来脚本开头处逻辑的清空了配置，这里的重点问题是containerd与cni，与openfaasd的复杂关系： Container Network Interface (CNI) 最早是由CoreOS发起的容器网络规范，是Kubernetes网络插件的基础。其基本思想为：Container Runtime在创建容器时，先创建好network namespace，然后调用CNI插件为这个netns配置网络，其后再启动容器内的进程。现已加入CNCF，成为CNCF主推的网络模型。CNI负责了在容器创建或删除期间的所有与网络相关的操作，它将创建所有规则以确保从容器进和出的网络连接正常，但它并不负责设置网络介质，例如创建网桥或分发路由以连接位于不同主机中的容器。 这个工作由openfaasd等完成。docker的这些组件->containerd+cni+ctr+runc，是由faasd来配置运行的。单独启动第一次安装完的containerd+cni+ctr+runc并不会启动cni和开启网卡(单独启动containerd提示cni conf not found没关系它依然会启动)，需要openfaasd中的动作给后者带来cni和网卡配置。但这种结合很紧密，使得接下来容器的完全清理工作有难度。 对于容器的清除，用ctr tasks kill && ctr tasks delete && ctr container delete可以看到ps aux|grep manual看到主机空间的shim任务和/proc/id号/ns都被删掉了，但还是某些地方有残留。这是因为这二者很难分开,shim开启的task关联容器和/var/run/containerd无法清理，导致前者很难单独拔插/进行配置卸载，也难于在下一次覆盖安装时能从0全新开始。 而这其实是一个bug导致的,containerd cannot properly do "clean-up" with shim process during start up? #3971（https://github.com/containerd/containerd/issues/3971），直到1.4.0beta才被解决（https://github.com/containerd/containerd/pull/4100/commits/488d6194f2080709d9667e00ff244fbdc7ff95b2），但我测试了(cd /var/lib/faasd/ faasd up)，只是效果好点，1.3.3是提示id exists不能重建container，1.40是提示/run/container下的files exists，同样没解决完全清理以全新覆盖安装containerd的需求，所以我脚本中提示了“containerd install+start progress(this may hang long and if you over install the script you may encount /run/containerd device busy error,for this case you need to reboot to fix after scripts finished”，这个基本如果你遇到了var/run删不掉错误，等安装程序跑完，重启即可。 因此我选择了1.40的containerd，它也同时解决了我开头提到的，gateway失效的问题。用的cni plugins还是0.8.5，本来想用那个cri-containerd-cni-1.4.0-linux-amd64.tar.gz,但里面的cni是0.7.1，与faasd要求的0.4.0不符。 对于cni的卸载和清除，则不属于ctr的能控制范畴，cni没有宿主机上的控制，除非将进程网络命名空间恢复到主机目录，或在在容器网络空间内运行IP命令来检查网络接口是否已正确设置，都挺麻烦，用上面删容器的ctr tasks kill && ctr tasks delete && ctr container delete三部曲删可以看到ifconfig中五个task对应的虚拟网卡也被干掉了，所以我也就没有再深入研究cni的卸载逻辑。 configdocker() { [[ $(systemctl is-active faasd-provider) == "activating" ]] && systemctl stop faasd-provider [[ $(systemctl is-active faasd) == "activating" ]] && systemctl stop faasd [[ $(systemctl is-active containerd) == "activating" ]] && ctr image remove docker.io/openfaas/basic-auth-plugin:0.18.18 docker.io/library/nats-streaming:0.11.2 docker.io/prom/prometheus:v2.14.0 docker.io/openfaas/gateway:0.18.18 docker.io/openfaas/queue-worker:0.11.2 && for i in basic-auth-plugin nats prometheus gateway queue-worker; do ctr tasks kill -s SIGKILL $i;ctr tasks delete $i;ctr container delete $i; done && systemctl stop containerd && sleep 10 ps -ef|grep containerd|awk '{print $2}'|xargs kill -9 rm -rf /var/run/containerd /run/containerd [[ ! -z "$(brctl show|grep openfaas0)" ]] && ifconfig openfaas0 down && brctl delbr openfaas0 rm -rf /etc/cni echo "===============================cniplugins installonly=================================" msg=$( #begin if [ ! -f "/tmp/cni-plugins-linux-amd64-v0.8.5.tar.gz" ]; then wget --no-check-certificate -qO- ${MIRROR_PATH}/docker/containernetworking/plugins/v0.8.5/cni-plugins-linux-amd64-v0.8.5.tar.gz > /tmp/cni-plugins-linux-amd64-v0.8.5.tar.gz fi mkdir -p /opt/cni/bin tar -xf /tmp/cni-plugins-linux-amd64-v0.8.5.tar.gz -C /opt/cni/bin /sbin/sysctl -w net.ipv4.conf.all.forwarding=1 2>&1) status=$? updateProgress 50 "$msg" "$status" "cniplugins installonly" echo "======containerd install+start progress(this may hang long and if you over install the script you may encount /run/containerd device busy error,for this case you need to reboot to fix after scripts finished)=====" msg=$( #begin # del original deb by docker.io rm -rf /usr/bin/containerd* /usr/bin/ctr # replace with new bins if [ ! -f "/tmp/containerd-1.4.0-linux-amd64.tar.gz" ]; then wget --no-check-certificate -qO- ${MIRROR_PATH}/docker/containerd/v1.4.0/containerd-1.4.0-linux-amd64.tar.gz > /tmp/containerd-1.4.0-linux-amd64.tar.gz fi tar -xf /tmp/containerd-1.4.0-linux-amd64.tar.gz -C ${INSTALL_DIR}/bin/ --strip-components=1 && ln -sf ${INSTALL_DIR}/bin/containerd* /usr/local/bin/ && ln -sf ${INSTALL_DIR}/bin/ctr /usr/local/bin/ctr rm -rf /etc/systemd/system/containerd.service cat << 'EOF' > /etc/systemd/system/containerd.service [Unit] Description=containerd container runtime Documentation=https://containerd.io After=network.target local-fs.target #After=network.target containerd.socket containerd.service #Requires=containerd.socket containerd.service [Service] ExecStartPre=-/sbin/modprobe overlay ExecStart=/usr/local/bin/containerd Type=notify Delegate=yes KillMode=process #changed to mixed to let systemctl stop containerd kill shims #KillMode=mixed Restart=always # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNPROC=infinity LimitCORE=infinity LimitNOFILE=1048576 # Comment TasksMax if your systemd version does not supports it. # Only systemd 226 and above support this version. TasksMax=infinity [Install] WantedBy=multi-user.target EOF systemctl daemon-reload && systemctl enable containerd systemctl start containerd --no-pager 2>&1) status=$? updateProgress 50 "$msg" "$status" "containerd install+start" } configdocker 未来等containerd的这个bug彻底解决或许有可能让containerd的shim task实现彻底停止和移除。来说点别的，还记得我在《enginx》中对openresty可以脚本编程转发连结游戏服务器的多组件集群，形成demo based programming的能力的设想吗(类似组成openfaas的五个containers，是组建一个单节点集群分布式的典型职责单位。有验证有网关，有业务)。还有基于jupyter的engitor，那么现在，我们用openfaas+vscodeonline来实现它们。我们知道openfaas这种就是构建一个分布式函数的“城市”，让城市组成的世界在二进制级，相互调用分布式API，进行demo组合，构成应用。是真正的demo积木编程。因为它可以Turn Any CLI into a Function，甚至是本地native cli。比如它能使shell完全变成分布式语言。直接在二进制上编程。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-10-27
panel.sh：一个nginx+docker的云函和在线IDE面板,发明你自己的paas(2)
继前文，这里介绍faasd和pai二个后端安装启动逻辑，也直接放代码： faasd 这里主要是将原来cloud-config.txt中cd git source root,faasd install替换成，经分析source/cmd/install.go后得到的几个静态文件，并将它们直接放进代码中，这样可以免除编译代码直接全部静态资源加脚本逻辑处理。 注意几处，1，/var/lib/faasd的权限一定要设成0755，而不是cmd/install.go中指定的0644。否则containerd启动不了，它要写hosts文件，以调用docker cni。2，结尾服务启动时，须留足充足的时间让images都下载完，只有下载完镜像才会启动网卡的。加了一些关于镜像和虚拟网卡是否准备完毕和唤起的判断，重点是离线镜像。 由于影响脚本失败的地方和可变因素主要来自镜像的拉取（及之后cni网络唤起，faasd up建立cni有一定机率让openfaas0网络出现很慢。），故设置了预拉取离线镜像并判断（本来之前计划是预配置cni，但与镜像部分结合紧密，且后来考虑到镜像拉取如果OK，cni过程应该无须再考虑）。使得onedrive+om可代替docker register仓库（github也有一个git bundle create offline-repos master，这对应我在《在openfaas面板上安装onemanager》文尾把git和docker仓库静态化的设想）。 # install faasd installOpenfaasd() { [[ $(systemctl is-active faasd-provider) == "activating" ]] && systemctl stop faasd-provider [[ $(systemctl is-active faasd) == "activating" ]] && systemctl stop faasd ps -ef|grep faasd|awk '{print $2}'|xargs kill -9 rm -rf ${INSTALL_DIR}/bin/faas* rm -rf /var/lib/faasd /var/lib/faasd-provider echo "=====faasd install+start progress(this may finally fail due to incorrect folder permissions or network issues,you can maunal fix it later with systemctl restart faasd)=====" msg=$( # begin if [ ! -f "/tmp/faas-cli" ]; then wget --no-check-certificate -qO- ${OPENFAAS_PATH}/faasd/0.9.5/faasd > /tmp/faasd fi cp /tmp/faasd ${INSTALL_DIR}/bin/faasd && chmod a+x ${INSTALL_DIR}/bin/faasd && ln -sf ${INSTALL_DIR}/bin/faasd /usr/local/bin/faasd #export GOPATH=$HOME # ...... #systemctl status -l faasd-provider --no-pager #systemctl status -l faasd --no-pager mkdir -p /var/lib/faasd && chmod 0755 /var/lib/faasd && mkdir -p /var/lib/faasd-provider && chmod 0755 /var/lib/faasd-provider && mkdir -p /var/lib/faasd/secrets rm -rf /var/lib/faasd/docker-compose.yaml cat << 'EOF' > /var/lib/faasd/docker-compose.yaml version: "3.7" services: basic-auth-plugin: image: "docker.io/openfaas/basic-auth-plugin:0.18.18ARCH_SUFFIX" environment: - port=8080 - secret_mount_path=/run/secrets - user_filename=basic-auth-user - pass_filename=basic-auth-password volumes: # we assume cwd == /var/lib/faasd - type: bind source: ./secrets/basic-auth-password target: /run/secrets/basic-auth-password - type: bind source: ./secrets/basic-auth-user target: /run/secrets/basic-auth-user cap_add: - CAP_NET_RAW nats: image: docker.io/library/nats-streaming:0.11.2 command: - "/nats-streaming-server" - "-m" - "8222" - "--store=memory" - "--cluster_id=faas-cluster" # ports: # - "127.0.0.1:8222:8222" prometheus: image: docker.io/prom/prometheus:v2.14.0 volumes: - type: bind source: ./prometheus.yml target: /etc/prometheus/prometheus.yml cap_add: - CAP_NET_RAW ports: - "127.0.0.1:9090:9090" gateway: image: "docker.io/openfaas/gateway:0.18.18ARCH_SUFFIX" environment: - basic_auth=true - functions_provider_url=http://faasd-provider:8081/ - direct_functions=false - read_timeout=60s - write_timeout=60s - upstream_timeout=65s - faas_nats_address=nats - faas_nats_port=4222 - auth_proxy_url=http://basic-auth-plugin:8080/validate - auth_proxy_pass_body=false - secret_mount_path=/run/secrets - scale_from_zero=true volumes: # we assume cwd == /var/lib/faasd - type: bind source: ./secrets/basic-auth-password target: /run/secrets/basic-auth-password - type: bind source: ./secrets/basic-auth-user target: /run/secrets/basic-auth-user cap_add: - CAP_NET_RAW depends_on: - basic-auth-plugin - nats - prometheus ports: - "8080:8080" queue-worker: image: docker.io/openfaas/queue-worker:0.11.2 environment: - faas_nats_address=nats - faas_nats_port=4222 - gateway_invoke=true - faas_gateway_address=gateway - ack_wait=5m5s - max_inflight=1 - write_debug=false - basic_auth=true - secret_mount_path=/run/secrets volumes: # we assume cwd == /var/lib/faasd - type: bind source: ./secrets/basic-auth-password target: /run/secrets/basic-auth-password - type: bind source: ./secrets/basic-auth-user target: /run/secrets/basic-auth-user cap_add: - CAP_NET_RAW depends_on: - nats EOF sed -i "s#ARCH_SUFFIX##g" /var/lib/faasd/docker-compose.yaml rm -rf /var/lib/faasd/prometheus.yml cat << 'EOF' > /var/lib/faasd/prometheus.yml # my global config global: scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. # scrape_timeout is set to the global default (10s). # Alertmanager configuration alerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: # - "first_rules.yml" # - "second_rules.yml" # A scrape configuration containing exactly one endpoint to scrape: # Here it's Prometheus itself. scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] - job_name: 'gateway' static_configs: - targets: ['gateway:8082'] EOF rm -rf /var/lib/faasd/resolv.conf cat << 'EOF' > /var/lib/faasd/resolv.conf nameserver 8.8.8.8 EOF rm -rf /var/lib/faasd-provider/resolv.conf cat << 'EOF' > /var/lib/faasd-provider/resolv.conf nameserver 8.8.8.8 EOF rm -rf /var/lib/faasd/secrets/basic-auth-user cat << 'EOF' > /var/lib/faasd/secrets/basic-auth-user admin EOF rm -rf /var/lib/faasd/secrets/basic-auth-password cat << 'EOF' > /var/lib/faasd/secrets/basic-auth-password PLEASECORRECTME EOF sed -i "s#PLEASECORRECTME#${PASS_INIT}#g" /var/lib/faasd/secrets/basic-auth-password rm -rf /etc/systemd/system/faasd-provider.service cat << 'EOF' > /etc/systemd/system/faasd-provider.service [Unit] Description=faasd-provider [Service] MemoryLimit=500M Environment="secret_mount_path=/var/lib/faasd/secrets" Environment="basic_auth=true" ExecStart=/usr/local/bin/faasd provider Restart=on-failure RestartSec=10s WorkingDirectory=/var/lib/faasd-provider # add # User=root [Install] WantedBy=multi-user.target EOF rm -rf /etc/systemd/system/faasd.service cat << 'EOF' > /etc/systemd/system/faasd.service [Unit] Description=faasd After=faasd-provider.service [Service] MemoryLimit=500M ExecStart=/usr/local/bin/faasd up Restart=on-failure RestartSec=10s WorkingDirectory=/var/lib/faasd # add # User=root [Install] WantedBy=multi-user.target EOF # in saftey,first downloads image and import them offline by advance if [ ! -f "/tmp/faasd-containers.tar.gz" ]; then wget --no-check-certificate -qO- ${OPENFAAS_PATH}/faasd/0.9.5/faasd-containers.tar.gz > /tmp/faasd-containers.tar.gz && tar -xf /tmp/faasd-containers.tar.gz -C /tmp fi ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/basic-auth-plugin-0.18.18.tar ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/nats-streaming-0.11.2.tar ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/gateway-0.18.18.tar ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/queue-worker-0.11.2.tar ctr --address=/run/containerd/containerd.sock image import /tmp/faasd-containers/prometheus-v2.14.0.tar systemctl daemon-reload && systemctl enable faasd-provider faasd systemctl start faasd-provider --no-pager systemctl start faasd --no-pager 2>&1) status=$? updateProgress 65 "$msg" "$status" "faasd install+start" # then, wait extra 30 for cni taking effort sleep 30 # finally check to ensure every container services and cni network being ready for i in 1 2 3; do [[ ! -z "$(ctr image list|grep basic-auth-plugin)" ]] && break;sleep 3;echo "checking basic-auth ($i),if failed at 3,it may require a reboot"; done for i in 1 2 3; do [[ ! -z "$(ctr image list|grep nats)" ]] && break;sleep 3;echo "checking nats ($i),if failed at 3,it may require a reboot"; done for i in 1 2 3; do [[ ! -z "$(ctr image list|grep prometheus)" ]] && break;sleep 3;echo "checking prometheus ($i),if failed at 3,it may require a reboot"; done for i in 1 2 3; do [[ ! -z "$(ctr image list|grep gateway)" ]] && break;sleep 3;echo "checking gateway ($i),failed at 3,it may require a reboot"; done for i in 1 2 3; do [[ ! -z "$(ctr image list|grep queue-worker)" ]] && break;sleep 3;echo "checking queueworker ($i),if failed at 3,it may require a reboot"; done for i in 1 2 3 4 5; do [[ ! -z "$(brctl show|grep openfaas0)" ]] && break;sleep 3;echo "checking openfaas0 ($i),if failed at 5,it may require a reboot"; done echo "=====================faas-cli install+login progress=======================" msg=$( #begin if [ ! -f "/tmp/faas-cli" ]; then wget --no-check-certificate -qO- ${OPENFAAS_PATH}/faas-cli/0.12.9/faas-cli > /tmp/faas-cli fi cp /tmp/faas-cli ${INSTALL_DIR}/bin/faas-cli && chmod a+x ${INSTALL_DIR}/bin/faas-cli && ln -sf ${INSTALL_DIR}/bin/faas-cli /usr/local/bin/faas && ln -sf ${INSTALL_DIR}/bin/faas-cli /usr/local/bin/faas-cli mkdir -p /var/lib/faasd/.docker ln -sf ~/.docker/config.json /var/lib/faasd/.docker/config.json sleep 5 && journalctl -u faasd --no-pager cat /var/lib/faasd/secrets/basic-auth-password | /usr/local/bin/faas-cli login --password-stdin 2>&1) status=$? updateProgress 70 "$msg" "$status" "faas-cli install+login" } pai 然后是pai的了,感觉没什么好说，就是把node跟vscode一样处理，将语言做进应用。因为node是带modules发布的。node是一个bootstrap，不像go的containerd，cni这些，是单个exe。我把pai整合了一下：把node-v10.16.2-linux-x64和pm2-3.5.1.tgz,serve-handler,sqlite3-4.1.1.tgz整合了，再把pai-mate-latest.tar.xz和node_modules.tar.xz整合了。最后把二者顶级文件夹整合的结果形成新的pai-mate-latest.tar.xz。这样也方便简化pai的脚本逻辑 # install paiserver installPai() { [[ $(systemctl is-active tencentcloud-pai-mate) == "activating" ]] && systemctl stop tencentcloud-pai-mate [[ $(systemctl is-active tencentcloud-pai-mate-update) == "activating" ]] && systemctl stop tencentcloud-pai-mate-update [[ $(systemctl is-active tencentcloud-pai-agent) == "activating" ]] && systemctl stop tencentcloud-pai-agent rm -rf ${INSTALL_DIR}/pai ${INSTALL_DIR}/pai-mate echo "=====================paimate install+start progress=======================" msg=$( # prepare directory mkdir -p ${INSTALL_DIR}/pai-mate # prepare mkdir -p ${INSTALL_DIR}/pai echo "export PATH=/root/.local/pai-mate/bin:$PATH" > ${INSTALL_DIR}/pai/pai-mate-env source ${INSTALL_DIR}/pai/pai-mate-env # get node/npm binary path # prepare workspace mkdir -p ${DATA_DIR}/pai_mate_workspaces # download package if [ ! -f "/tmp/pai-mate-latest.tar.xz" ]; then wget --no-check-certificate -qO- ${PAI_MATE_SERVER_PATH}/pai-mate-latest.tar.xz > /tmp/pai-mate-latest.tar.xz fi # unzip tar -Jxf /tmp/pai-mate-latest.tar.xz -C ${INSTALL_DIR}/pai-mate mv /tmp/pai-mate-latest.tar.xz /tmp/pai-mate-latest.tar.xz.old cd ${INSTALL_DIR}/pai-mate # config echo "UPDATE_PATH: ${PAI_MATE_SERVER_PATH}" > config.yml echo "DOMAIN_NAME: ${DOMAIN_NAME}" >> config.yml echo "CERT_PATH: /etc/letsencrypt/live/${DOMAIN_NAME}/fullchain.pem" >> config.yml echo "KEY_PATH: /etc/letsencrypt/live/${DOMAIN_NAME}/privkey.pem" >> config.yml #npm install --production --unsafe-perm=true --allow-root npm run migrate:latest # systemd service start rm -rf /etc/systemd/system/tencentcloud-pai-mate.service cat << 'EOF' > /etc/systemd/system/tencentcloud-pai-mate.service [Unit] Description=Tencent Cloud Pai Mate After=network.target [Service] Type=simple Restart=always RestartSec=1 User=root Environment=PATH=/root/.local/pai-mate/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin WorkingDirectory=/root/.local/pai-mate ExecStart=/root/.local/pai-mate/bin/start.sh [Install] WantedBy=multi-user.target EOF rm -rf /etc/systemd/system/tencentcloud-pai-mate-update.service cat << 'EOF' > /etc/systemd/system/tencentcloud-pai-mate-update.service [Unit] Description=Tencent Cloud Pai Mate Update After=network.target [Service] Type=oneshot User=root Environment=PATH=/root/.local/pai-mate/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin WorkingDirectory=/root/.local/pai-mate ExecStart=/root/.local/pai-mate/bin/update.sh EOF rm -rf /etc/systemd/system/tencentcloud-pai-mate-update.timer cat << 'EOF' > /etc/systemd/system/tencentcloud-pai-mate-update.timer [Unit] Description=Tencent Cloud Pai Mate Update [Timer] OnCalendar=daily RandomizedDelaySec=5minutes Persistent=true [Install] WantedBy=timers.target EOF chmod +x ${INSTALL_DIR}/pai-mate/bin/* systemctl daemon-reload systemctl enable tencentcloud-pai-mate.service systemctl start tencentcloud-pai-mate.service systemctl start tencentcloud-pai-mate-update.timer 2>&1) status=$? updateProgress 90 "$msg" "$status" "paimate install+start" echo "=====================pai install+start progress=======================" msg=$(#begin mkdir -p ${INSTALL_DIR}/pai/etc mkdir -p ${INSTALL_DIR}/pai/bin echo "server_path: ${SERVER_PATH}" > ${INSTALL_DIR}/pai/etc/pai.yml echo "domain_name: ${DOMAIN_NAME}" >> ${INSTALL_DIR}/pai/etc/pai.yml # Note: `agent` binary will update and run this time. `baker` binay will be run next time. # cannot overwrite binay, error: text busy # mv -f "${INSTALL_DIR}/pai/bin/pai_agent" "${INSTALL_DIR}/pai/bin/pai_agent.old" # mv -f "${INSTALL_DIR}/pai/bin/pai_baker" "${INSTALL_DIR}/pai/bin/pai_baker.old" wget --no-check-certificate -qO- "${SERVER_PATH}/bin/pai_agent" > "${INSTALL_DIR}/pai/bin/pai_agent" # curl "${SERVER_PATH}/bin/pai_baker" -sSf > "${INSTALL_DIR}/pai/bin/pai_baker" chmod +x "${INSTALL_DIR}/pai/bin/pai_agent" # chmod +x "${INSTALL_DIR}/pai/bin/pai_baker" rm -rf /etc/systemd/system/tencentcloud-pai-agent.service cat << 'EOF' > /etc/systemd/system/tencentcloud-pai-agent.service [Unit] Description=Tencent Cloud Pai Agent After=network.target [Service] Type=simple Restart=always RestartSec=1 User=root ExecStart=/root/.local/pai/bin/pai_agent [Install] WantedBy=multi-user.target EOF rm -rf /etc/systemd/system/tencentcloud-pai-baker.timer cat << 'EOF' > /etc/systemd/system/tencentcloud-pai-baker.timer [Unit] Description=Tencent Cloud Pai Baker [Timer] OnCalendar=daily RandomizedDelaySec=5minutes #OnCalendar=*-*-* *:*:00 Persistent=true [Install] WantedBy=timers.target EOF systemctl daemon-reload systemctl enable tencentcloud-pai-agent.service systemctl start tencentcloud-pai-agent.service 2>&1) # systemctl restart tencentcloud-pai-baker.timer status=$? updateProgress 100 "$msg" "$status" "pai install+start" } if [ $PANEL_TYPE == "0" ]; then installOpenfaasd else installPai fi vscodeonline和结束部分 # install codeserver installCodeserver() { [[ $(systemctl is-active code-server) == "activating" ]] && systemctl stop code-server rm -rf ${INSTALL_DIR}/bin/code-server ${INSTALL_DIR}/lib/code-server-3.5.0 ${CONFIG_DIR}/code-server echo "=====================codeserver install+start progress=======================" msg=$(# begin mkdir -p ${INSTALL_DIR}/lib/code-server-3.5.0 ${INSTALL_DIR}/bin ${CONFIG_DIR}/code-server if [ ! -f "/tmp/code-server-3.5.0-linux-amd64.tar.gz" ]; then wget --no-check-certificate -qO- ${CODE_SERVER_PATH}/v3.5.0/code-server-3.5.0-linux-amd64.tar.gz > /tmp/code-server-3.5.0-linux-amd64.tar.gz fi tar -xf /tmp/code-server-3.5.0-linux-amd64.tar.gz -C ${INSTALL_DIR}/lib/code-server-3.5.0 --strip-components=1 ln -s ${INSTALL_DIR}/lib/code-server-3.5.0/bin/code-server /usr/local/bin/code-server # systemd service start rm -rf ${CONFIG_DIR}/code-server/config.yaml cat << 'EOF' > ${CONFIG_DIR}/code-server/config.yaml bind-addr: 127.0.0.1:5000 auth: password password: PLEASECORRECTME cert: false EOF sed -i "s#PLEASECORRECTME#${PASS_INIT}#g" ${CONFIG_DIR}/code-server/config.yaml # systemd service start rm -rf /etc/systemd/system/code-server.service cat << 'EOF' > /etc/systemd/system/code-server.service [Unit] Description=code-server After=network.target [Service] Type=exec ExecStart=/usr/local/bin/code-server Restart=always User=root [Install] WantedBy=default.target EOF systemctl daemon-reload && systemctl enable code-server systemctl start code-server 2>&1) status=$? updateProgress 100 "$msg" "$status" "code-server install+start" } installCodeserver echo "=====================finished .....=====================" if [ $PANEL_TYPE == "0" ]; then echo "the final admin panel url you can access(login with user name admin and passwd given): https://${DOMAIN_NAME}/faasd/,password is '$(cat /var/lib/faasd/secrets/basic-auth-password)',thevscodewebide server at:https://${DOMAIN_NAME}/codeserver/,password is ${PASS_INIT},thank you!!" else echo "the final admin panel url you can access(login with your valid cvm account): https://${DOMAIN_NAME}/pai/,datadir is ${DATA_DIR},thevscodewebide server at:https://${DOMAIN_NAME}/codeserver/,password is ${PASS_INIT},thank you!!" fi # count time endTime=$(date +%s) echo 'Total Time Spent: '$((endTime-beginTime))'s' 如果安装后你更改了密码，可以systemctl restart faasd faasd-provider containerd使之生效。刚刚收到短信20201012,腾讯scf免费要改为一年之后收费了，还是自备云函的好 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-29
在云主机上安装vscodeonline
本文关键字：teamviewer保持在线的替代品把vscode terminal当虚拟主机管理面板。remote-openfaas,打造vscodeos:用插件打通openfaas界面到vscodeonline，实现ide.sh与云函数容器对接 在前面《云主机上部署pai》,《云主机上部署openfaas》中，我们用同样风格的脚本写出了在云主机上部署的二个paas面板，pai类似虚拟主机管理器，而openfaas是paas->faas，综合这二者都是部署和devops面板，它们在透出的界面5523,8080处用web操作。然后我们在《戒掉PC，免pc开发，cloud ide and debug设想》又遇到了vscodeonline，这三者都是云主机构造paas APP以“在线开发和部署”的OS扩展，体验良好度又都有前后分离十分接近，因此，我们这次也把vscodeonline集成在这里，组成成为minstackos的主要部分。未来，我们把所有讲到的paas app用这些面板串联起来，使它们成为可一键在线开发和部署的APP，形成minstackos的appstore来源。 在《在openfaas面板上安装onemanager》中我们讲过云主机的ssh往往是很容易断的，如果是graphic linux下，需要tv这样的这样的远程桌面方案来保持长时间在线，但实际上，vscodeonline也有linux终端面板。remote-ssh连接的vscodeonline可以保持长时间ws在线而且可以点上面的一个图标扩展到整个IDE的编辑区。因此体验上，后者可成为前者的良好替代。 好了不废话了。下面依然在一台ubuntu 1h2g上进行。 基础 一些变量 MIRROR_PATH="http://default-8g95m46n2bd18f80.service.tcloudbase.com/d/demos" # the code-server web ide CODE_SERVER_PATH=${MIRROR_PATH}/codeserver 安装codeserver 脚本被做成融合成安装pai和openfaas的风格，按standalone方式安装,以root身份运行。你可以集成自己需要的语言和插件服务到这个IDE，以做到尽量开箱即用。 # install codeserver installCodeserver() { echo "=====================codeserver install progress=======================" msg=$(mkdir -p ~/.local/lib/code-server-3.5.0 wget --no-check-certificate -qO- ${CODE_SERVER_PATH}/v3.5.0/code-server-3.5.0-linux-amd64.tar.gz > /tmp/code-server-3.5.0-linux-amd64.tar.gz && tar -xvf /tmp/code-server-3.5.0-linux-amd64.tar.gz -C ~/.local/lib/code-server-3.5.0 --strip-components=1 rm -rf /tmp/code-server-3.5.0-linux-amd64.tar.gz ln -s ~/.local/lib/code-server-3.5.0/bin/code-server ~/.local/bin/code-server PATH="~/.local/bin:$PATH" # systemd service start rm -rf ~/.config/code-server/config.yaml cat << 'EOF' > ~/.config/code-server/config.yaml bind-addr: 0.0.0.0:5000 auth: password password: pleasecorrectme cert: false EOF # systemd service start rm -rf /etc/systemd/system/code-server.service cat << 'EOF' > /etc/systemd/system/code-server.service [Unit] Description=code-server After=network.target [Service] Type=exec ExecStart=~/.local/bin/code-server Restart=always User=root [Install] WantedBy=default.target EOF systemctl daemon-reload && systemctl enable code-server systemctl start code-server 2>&1) status=$? updateProgress 95 "$msg" "$status" "code-server install" } 安装完成后记得修改~/.config/code-server/config.yaml下的密码，端口为5000。如果你要用上证书，就最好搭配脚本中的nginx+certbot申请的那个。cert: false也可以用假的localhost的那个，但是基本没有什么用。 其实，利用那个remote-container，可以把openfaas-cli跟vscode连起来，利用工程源文件下的yml模板（.pai.yml,openfaas-cli.yml,etc...）文件打造一个带开发部署的工程资源组织文件，形成remote-openfaas效果：多环境多语言下，需要频繁切换环境，一次开发总是跟一次塔环境开始的，这也是vagrant和docker对于开发的意义（以前是vm，没有模板机制），而docker用于开发也用于部署。以后一套APP天然就有一个online webide守护，自带开发环境了。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
戒掉PC，免pc开发，cloud ide and debug设想
本文关键字：分布式IDE，cloudide，远程编码，远程调试,jupyter with visual debugger support 编程界有关于语言的圣战，OS之争，也甚至有代码编辑器是选择cui text ide还是gui IDE的选择的讨论。这次我们讲的是云IDE，其实，我们一直讲的是devops和云可视IDE这类服务端直接支持的开发部署，从《ellie可视化》到《docker as snippter空间》，从《一种设想：在网盘里coding,debuging，运行linux rootfs作全面devops》到《分布式IDE：osx一个完美的开发集中》，这些都是从不同层面去说的，毕竟这样一个工作要解决好多问题，而为什么要把开发做上云的理由也很明了：devops在云端，服务器环境入口网络好。我们也一直在寻求某种“免PC的开发”：如果把发布部署做上云了，如在《去windows去PC，打造for程序员的碎片化programming pad硬件选型》中所讲一样，我们甚至不需要一台PC仅需要一个平板就可以在云端构建，或者一个专用programmingpad，，实现戒掉PC把一切放到远端，免除本地重复部署，比如借助devops可以在一次性的虚拟沙盒环境中编程部署，干净，永远守护，开箱待用，，----- 它是云OS扩展一级的东西，与lnmp,openfaas云开发云部署同级，如果说后者解决的是部署前者解决的就是开发调试，当然也有将二者结合的，我们甚至谈到一种天然绑定debug设施的os和appstack结构(press esc切换运行态/开发态)。 云 IDE是新概念吗？不不不，早在 2010 年就有成熟的产品了，其实类似baota panel的文件管理器当cloud ide也可以，但是毕竟它缺乏真正的开发所需的一条路径上的东西。云调试与云编程支持。这里的技术是把IDE分布化，基础原理依然是设置协议（语言服务，调试服务API后端化）和前后端分开，这样前端可以ported到任何设备，《用开发本地tcpip程序的思路开发webapp》讲到，Api分离，实际上是从业务逻辑中分离了gui栈，这是一种经典的抽象，也是很久以前桌面界的编程方案了。其实web不是没有过前后分离，只不过很晚才将前后分离做到云函数和devops式建立api服务池的程度。 目前有很多实现，但我们接确到的大都就是jupyter和vscode online这二个，jupyter面向文档嵌入代码领域而vs code online面向真正的传统IDE在线化，它们二者都有明显的前后协议层支持。针对语言编程和调试。它们二者都可以与docker打通，而docker实际上是一个贯通开发部署综合的devops，所以与devops又有了联系。 vscode/vscode online 微软向云靠拢其营收已超过windows本身。github,azure,onedrive,vscode/vscodeonline都是例子，微软在 Build 2019 开发者5月份的大会上宣布了 Web 版本的 VS Code，即 Visual Studio Online Private Preview。在 2019 11 月 4 日发布公开预览版的 Visual Studio Online。 实现： 其实vscode本来就是一个分布式IDE和云化版本。(vscode本来一开始就是面向要被online的，它的插件设计规范中的Language Server Protocol，Debug Adapter Protocol就决定了,vscode的设计师一开始就是从分布式角度去做的),前端上，从页面上直观地看，VS Online 就是一个 Web 版的 VS Code，vscode使用Electron(原来叫 Atom Shell),桌面vscode最初也是由atom而来，这使得前端很容易被ported到web，但这其实只是它的一个前端界面，而 VS Online 更强大的能力来自于vscode-server+remote development extensions，这里我们暂时把web或桌面那个editor界面称为前端，vscodeserver+remotedevelopment exs称为后端。 在vscode中，如果你使用了remote-devopment中的ssh组件（一般地，你用remote-ssh远程开发，用remote-container本地），会自动在远端下载vscode-server，这并不仅仅是打开远程文件这么简单（这仅属于工程组织文件托管范畴和代码托管），而是连IDE和插件服务都做在了远端了。------ 单纯的remote-developer是一个插件包，是用了同步/打开远程文件用的。在vscode的插件搜索栏中，搜remote插件出来的东西多得你理解不透。大部分是解决代码托管一类的，解决类似在wxsdk tool云函数同步到后端的功能(tencent-cloud-vscode-toolkit)，git可能是提交工具也可以是代码空间也可以是工程文件组织器。比如remote-github(注意到云函数和一些git平台，都有ide，只是git配ide白瞎了，因为没有调试的可能性。不过，虽然目前只是在测试阶段，微软已经实现了为github集成了基于vscodeonline的不离开页面的沉浸式webide,github人类的代码基因库结合全能可用的webide，这是极佳的整合和创新。),你要的那种网盘文件。codesnippter空间也有。类似google colab 网盘挂载。------ 真正发挥作用的是后端插件管理和其组成的那个IDE(ide是由大量plugins组成的嘛)服务，这正是vscode-server。只是架构上,，这个vscode-server，被没有被做成统一后端，vscode-server不能按版本单独部署，必须要用一个vscode-server-client来唤起部署，vscode-server按需部署必须至少绑定一个front。这二者不能随意组合,也没有配置项将IDE前端和vscode-server连接起来，所以，没用到远程插件服务的情况下，本地vscode开发并不需用到（比如，同为remote的remote-container并不需要用到vscodeserver?）。 所以，不满足桌面？不想使用浏览器？这也不是什么大问题，由于它的前后端分离，可以将vscode online接入后端云开发环境（或本地模拟出来的“远程”版本，不过这样失去了云存储和云开发的某些意义）把它变成vscode。同样可做到类本地vscode效果。。而vscode online是前后可分离,服务端可以是本地模拟的也可是真正远程的，更自由，允许桌面版连接服务端远程开发，不局限于web as front，当然如果可以你也可以定制出你自己的vscode online。如果你想任意组合这二者，实现"让web/桌面vscode统一remote后端"的功能：比如，你想在本地搭建一个GUI前端(仅把它当editor front)，却想调用后端的ide服务和插件，最终是为了编辑开发托管代码，或调用远程docker里面的应用呢，这当然也是可以做到的，1，自建codespace服务器(可以把它理解为桌面那个editor前端+vscodeserver)，在目标机器上安装 VS Code，搜索Visual Studio Codespaces (formerly Visual Studio Online)安装，并命令中注册，它的原理应该也是部署了一个vscodeserver。2，可以在远程直接安装github/cdr/code-server的那个web版，然后查看它带的codeserver版本，来决定本地桌面端可能会用上的版本对上，file->about->help可以看到它采用的code-oss版本和commitid。（2比1好，毕竟自带一个web前端是最基本的，桌面和移动端可以作为额外项添加） 这样你可远程同步代码 + 本地调试，远程托管代码+远程调试，也可本地代码+本地调试（vscode itself），也可以本地代码，远程调试。当然也有对接重量级docker和devops的。甚至上面谈到的“一次性的虚拟沙盒环境中编程部署”，代替程序员日常的维护多个虚拟机完成不同开发工作的需求(还记得程序员下班不关机这梗吗)。这就是remote Container。 vscode/vscodeonline开源在github，叫Code - OSS,其源码倒是没有缺失和阉割也有完善的构建支持（https://github.com/Microsoft/vscode/wiki/How-to-Contribute#build-and-run），mit的开源许可也很友好，但是vscode二进制本身是this not-FLOSS license 的并带了telemetry/tracking，而且其remote-development却是不开源的，且规定二进制vscode-server不能被打包（见https://code.visualstudio.com/docs/remote/faq，Can VS Code Server be installed or used on its own?Why aren't the Remote Development extensions or their components open source?）。所以，类似code-server,Che,VSCodium这样的公司和产品就只能自己编译源码。集成docker devops运营（https://opensource.com/article/20/6/open-source-alternatives-vs-code）。https://zhuanlan.zhihu.com/p/98184765,code-server是vscode的魔改版本(基本上，code-server采用了vscodeonline里面的vscode-server组件+web前端，由于code-server必须要绑定一个前端，这造成code-server是前后一体放在远端只能web界面)。微软也有托管计划Visual Studio Codespaces。code-server也有。 体验: 这就要说到体验了，追求一种存储也在远程，而且最好一条龙开发部署都在远端的IDE。一切硬件无线和软件云化的云计算时代，讲究没有任何随身携带的东西，体验就跟使用云笔记一样（云上存储空间和执行空间全包，作为后端，前端只需要要一个GUI，前后端通过协议跨架构交互）因此在PC和手机上都有支持。云IDE这样的东西最讲究体验，体验是第一位的，比如它比本地版本不要落后太多。web端的肯定跟本地的前端，移动的前端会有区别，体验和技术上的 移动端有ios的Servediter（以前的vsapp），jupyter也有这类APP叫juno connect。macbook要arm化。也支持ipad开发，当然，功能可能稍微会有点受限。安卓端当然也有。这里的体验差别就更大了去了。 只是说实话我对ssh的稳定性很不放心。说实话它真不如一个网盘客户端（最好是一个类finder的集成在file explorer中）,不过市场中也有cloudsync的插件。web端的体验其实还可以，只要不刷新网页后台一直websocket连着。 jupyter jupyter notebook最初来自于julia和科学计算，叫ipython,后来发展成了通用notebook工具。以前，我们曾介绍过它也是一个devops。因为它可以结合docker形成binder这样的平台和工具。jupyter只是个notebook，最初它用用来写文档中的代码块。后来被作为语言学习平台。不是面向生产和真正的IDE的。这类产品是cloudide，比如vscode/vscodeonline，VS Code 也有对它的支持：Jupyter Notebook Editor。 jupyter也是前后端分离开发的典型，它有一个协议系统，这种分离使得前端可以不限于webasfront，也可以是mobileapp。甚至小程序这种嵌入前端。比如第一步要将语言发展为repl(脚本语言天然有repl，而cpp这样的要借助一定手段或现有产品变通。如cling)，然后按jupyter的语言kernel协议写成插件接上jupyter。 它也有很多泛化产品：如接上docker的binder，如基于jupyter notebook的jupyter book(注意名字区别)，叫可执行的markdown（就是在md中嵌入ipynb片断，或者理解成在ipynb中写markdown），进一步可发展为利用云snippter笔记写blog,可导出整书pdf（我还没找到按toc能整书生成pdf的产品，那就成word了，gitbook算一个）。 还有如基于jupyter的可视调试：jupyterlab/ debugger。当然它也是分前后端和协议实现的。这就一步一步走向了真正的cloudide的段位了。 如果说上一代jupyter是面向文学编程和科学研究的，下一代是称为Jupyterlab的产品就有点ide的味道了，有Elyra这样的产品了。 下一文探索发明lang.sh:把jupyter with debugger supporter和code-server整合安装在minstackos (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
在openfaas面板上安装onemanager（2）
本文关键字：openfaas onemanager,nginx仅监听ipv4，disabling IPv6 name/address support: Address family not supported by protocol 在前面《在openfaas面板上安装onemanager》中我们讲到自建云函数将om放到自己服务器的方法，但是遗留了一些问题，1，经常会有“error finding function onemanagerforopenfaas.: Get http://faasd-provider:8081/system/function/onemanagerforopenfaas?namespace=: dial tcp: i/o timeout”，2，整个应用访问延时感比较明显（这些在腾讯scf也有,容器是多层虚拟化有抽象成本），但在faasd中，还有其它一些导致延时的问题。3，程序中有一些路径不对，readme.md可以显示，但压缩文件下载不了显示页面返回空白，4，/function/xxx/的形式也长。 第一个问题，我们得去了解faasd的机制，在安装步骤的cd faasd src,git checkout 0.9.2,faasd install时，它利用一个faasd bin启动了二个过程，faasd up和faasd provider，ps aux|grep faasd可看到二进程的路径，netstat -tlp | grep -i faasd或lsof -i:8080可看到端口（注意到它们都绑定在了ipv6），这里的逻辑如下： faasd deploys OpenFaaS along with its core logic faasd-provider, which uses containerd to start, stop, and manage functions.The faasd process will proxy any incoming requests on HTTP port 8080 to the OpenFaaS gateway container。 解析一下：云函数首先是个容器集群，faasd维护一个单机容器集群和一个内部网络(这种东西在《利用colinux制作tinycolinx，在ecs上打造server farm和vps iaas环境代替docker》一文中我们提到单机构造集群的例子，多个vm要重用80，再想象一下，虚拟机用得多吧，也要接确到与宿主的多种网络出入逻辑和子网逻辑。在《openaccess》一文中也讲到过,openaccess虚拟局域网，这些都是虚拟网络的例子。只不过这次是管理单机上（或集群）上的容器集。）多个容器pod也要network，这个用linux上的iptables转发就可以办到，但容器为了功能强大往大了做，它使用了cni。体现在openfaas端（/etc/cni/net.d），就是它在本地网卡和虚拟的cni openfaas网卡之间转发实体间占用虚拟网卡的IP空间，faasd自己维护一个这样带自我解析的机制从而做到不依赖于dns，它们都cat /var/lib/faasd/hosts和cat /var/lib/faasd/docker-composer.yml中可以看到定义。 我们发现，到最终应用，整个serverless机制，它就是faasd+cni+一堆容器堆出来的，gateway是容器，在10.62.0.1网关(这个由cni做出来的openfaas0网卡)，watchdog也是容器。app也是容器。只是hosts中没有app的10.62.0.xx的ip地址。ps aux | grep onemanager可以看到它是一个containerd-shim-runc-v2容器进程，每次重启后这个docker本身有一个ip 10.62的ip( journalctl -u faasd --lines 40，出现onemanagerforopenfaas has IP: 10.62.0.xxx获得)，每次deploy后也会换，你会发现每打开一个链接，lsof -i:8080都会增加几个进程，这就是openfaas的云函数机制，它是按需为访问活动中的函数（从后端容器进程中提取,我们知道，容器运行时即容器的实现方法，现在有很多种，不光docker。containerd也是）生成进程的，等到这些访问活动没了，它就自动消失，没有一个像httpd daemon的守护（这是延时的由来原因之一），faasd负责管理所有这一切。 无论如何，作为serverless，faasd这样做的好处是：（这样做的意义，在于最大利用单机上的资源，而且以可伸缩的方式，所以同样可以有集群方案），且你可以用为语言贡献库的方式去开发远程服务性APP。因为它们是直接php index.php或go index.go弄起来的 Any binary can become a function through the use of watchdog.，开发接上了部署都在API级（带容器集群开发/部署级别的faas给devops带来的功效相当于另一种带visual ide as devops的集成appstack环境）。而且这种非http方式提高了利用率。不过单机上的应用集群局限于单机的最大能力，而集群上的应用则不会。 解决问题1，2 来看第一个问题，我们猜它是发现不了docker-composer.yml中http://faasd-provider:8081中的faasd-provider对应的ip，于是我们把yml中的地址替换成10.62.01。问题1，解决。但随后经常出现“service not reachable for onemanagerforopenfaas”，（但这个其实访问很流畅：http://m.shalol.com:8081/system/function/onemanagerforopenfaas?namespace=-），于是我们查看日志：sudo journalctl -u faasd-provider --lines 40，发现error with proxy request to: http://10.62.0.xxx:8080/，这就是containerd的原始进程经过gateway代理的过程中出现的。我们要把它弄成ipv4的listen,如何在ipv4上启动faasd试试： 在ubuntu上关掉ipv6，我尝试过sysctl关掉所有网卡，禁掉/etc/hosts所有[::]:等方案都不行，最后etc/default/grub中修改GRUB_CMDLINE_LINUX_DEFAULT="quiet spalsh"为GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet splash"然后update-grub重启成功。再次netstat发现faasd进程都被forced to use ipv4了(不过听说faasd升到0.9.5，源码中有ip修改的地方，如果不是默认的空或者0或者0.0.0.0，那么都可以成功在IPv4下建立侦听。)。问题2延时减少了很多，（无论是直接访问原始容器还是代理到gateway的8080）“service not reachable for onemanagerforopenfaas”出现的机率都减少了很多(进入系统多等，或要访问应用至少一次，faasd-provider才会启动,这是40秒docker自定义网络延时？)。 但是nginx却启动不了了，考虑到禁用了ipv6,于是我把/etc/nginx/conf.d/default.conf中listen [::]:都注释掉了，但还是启动不了（网上说的那些ipv6 on的方法也不管用），我的是ubuntu18.04上的nginx 10.14.2，这是因为跟faasd一样，Nginx is doing DNS resolution at startup by default，在ubuntu上，With current default vhost listening on IPV6, nginx won't start on fully IPV6 disabled system, expecting to connect to a IPV6 socket on port 80.但是在其它发行版Other distributions does that (not including ipv6 listen by default) already (e.g. Centos and Upstream)，不过This bug was fixed in the package nginx - 1.17.5-0ubuntu1，于是 sudo touch /etc/apt/sources.list.d/nginx.list deb [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ bionic nginx deb-src http://nginx.org/packages/mainline/ubuntu/ bionic nginx wget http://nginx.org/keys/nginx_signing.key sudo apt-key add nginx_signing.key sudo apt update sudo apt remove nginx nginx-common nginx-full nginx-core 如果apt包管理器询问你是否要安装新版本的/etc/nginx/nginx.conf文件，则可以回答否，以保留原来的注释掉了[::]:的config. 成功。 关于延时，watch-dog有一个特化版，可以将一般进程转为长驻留的http，这种方式下Keep function process warm for lower latency / caching / persistent connections through using HTTP，延时不会因为频繁经过网关开进程导致开销(否则你需要定时访问触发以触发网关warm up这个function)，而且它支持webframework，因为里面可以内嵌一个webserver(虚拟机管理面板中，为什么php cgi很容易跟nginx组合，配置成熟，很多细节可以配置，而python项目管理就相对少一些。因为php cgi自带了服务进程管理相当于这里的watchdog作为外部，框架放在内部源码部分仅涉及到业务逻辑不涉及到服务管理，内外分开，而python这样的没有cgi这样的东西，框架管理进程，直接在里面开服务。这种细节在外部与nginx组合的时候显得难于配置)，webframework可以允许你定制一次请求响应和url router，允许你用类似js的event,content方式开发。使用这种watch-dog，需要： FROM openfaas/of-watchdog:0.7.7 as watchdog 最下面ENV fprocess="php index.php"之后加： ENV mode="http" ENV upstream_url="http://127.0.0.1:5000" (框架服务器透出的转发地址，转到watchdog:8080) 由于上述方案适合这种框架中自带服务器的，onemanager并不适用，所以我没尝试。它还支持一种mode=static，想到pai中那个static:public了吗？在支持statcisite方面，上次说到pai需要手动一次，因为它使用的是devops的一个部件git，而没有使用到devops的主要部件docker。这里用了云函数这种方案，就纯自动了。 解决问题3 你会发现地址不对了。这时在common.php中作以下替换：$_SERVER['base_disk_path'] . '/' . $path$_SERVER['base_disk_path'] . '/' . 'function/onemanagerforopenfaas/' . $path有大约七处。 对于那个文件下载不了了的问题显示空白，curl_setopt是common.php中onemanager向上面的api要求结果的函数。影响着向下面的客户返回的结果。你可以在本地模拟curl -I 正常的om的下载返回结果，修改common.php以让整个程序也返回同样的结果。 另外发现一个可在common.php中markdown替换网址，以实现在域名子目录里放md网站效果的功能，(如果不这样，则你需要在md中定制带此目录的域名根路径)。这个其实跟domainforproxy一样可以做成后台配置项。 因为我使用了parsedown，你也可以在原始的$headmd输入中替换： $headmd = str_replace('<!--HeadmdContent-->', $parser->text(str_replace('/p/','/minlearnprogramming/p/',fetch_files(spurlencode(path_format(urldecode($path) . '/readme.md'),'/'))['content']['body'])), $tmp[0]); 被一个腾讯cvm的问题折腾了好久，别人能正常ssh我的服务器，我在本机却不能(没有任何响应)。web ssh下，别人和我都不能wget，提示no response。解决办法是去管理台切换一下172.16.0.xxx形式的私网地址。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
在openfaas面板上安装onemanager
本文关键字：openfaas onemanager 在前面《在云主机上手动安装腾讯PAI面板》《利用openfaas faasd在你的云主机上部署function serverless面板》中，我们介绍了二种虚拟主机/容器后端，它们都可以搭配nginx作为前端，形成webstack，和通用服务器应用栈，而且都支持多语言，支持devops部署。其中，前者用git作devops，后者用容器（faasd中用containerd），后者的devops更全面：要知道，现在的devops构建基本是用docker完成的，无容器不devops。况且，openfaas是对我《最小编程学习集与开发栈选型：1，语言选型与开发融合，2，云系统，云服务器，虚拟boot，语言运行时和应用容器，及平台融合，3，云APPSTACK云调试云DEVOPS及开发融合》中的2，3的整个暂代实现（替代目前还无法做到的统一语言，统一内核）,它与我的cloverboot+黑群晖黑苹果等cloud os，组成了一个暂代可用的minstackos:一个企图将包括上面1，2，3的最小开发栈实现做入boot的方案。 其实老早就接确过docker和k8s,swarm这种容器管理面板，但是一直没怎么深入使用(有这功夫为何不研究coreos?)，一是对docker aufs不放心(二是docker本身虽然利用了内核功能，但是本体属于在应用级用虚拟化重新构建网络和文件系统，带来较高负担和延时)，二是swarm,k8s这种比较重，直到接确云函数，再到这里的轻量级faasd，才发现基于容器的面板也可以很轻量（当然，pure k8s和云函化的容器面板还是有点不一样的）。二是云函数本身就关注用它运行功能，而不用涉及到存放数据，因此docker aufs这种可能导致文件系统污染的缺陷也就不足于当回事了。最后这种容器用于生产环境的缺陷慢慢也正在基本被彻底修复。 faasd用的是containerd，但使用docker构建应用，注意这里的docker-ce只是离线构建openfaas/faasd用的docker镜像之用，并不会加大faasd的运行时，这里提到openfaasd用docker image as app meta(dockfile vs pai.yml)，没错，openfaas用docker作devops。所以可以封装构建流程。而不仅仅像pai面板那样停留于用git拉取。 下面，接上文《利用openfaas faasd在你的云主机上部署function serverless面板》，我们将onemanager移过来。----- 为什么不是fodi,fodi毕竟没有url,不利于运营。 好了，不费话。 调试与基础 调试，前调试后调试，都是运维开发的必要过程，甚至是主要过程。因为它是搞清问题的必要实验过程。 在faasd所在主机上apt-get install docker-ce，我在faasd所在主机是一台装上了deepin20a的云主机，因为这样结合teamviewer可以远程桌面(linux上远程桌面大部分都是位图截取算法的不要用。tv效率高，支持本地远程剪贴板交互，而且tv还有一个图形scp功能。deepin+1h2g开2g swap完全可以驾驭，开机只占1G内存)可以长时间保持在线，而不必总是用本地的ssh(十分易断)， 还有，faasd构建应用涉及到大量与docker.io的交互，这个在国内云主机网络环境下速度是很弱的，虽然有一些方案支持自建docker registry给faasd用，但是太折腾，不如在云主机上装v工具，然后命令行下export http/https_proxy。而且，dokcer-cli是支持应用级proxy的， sudo mkdir -p /etc/systemd/system/docker.service.d sudo touch /etc/systemd/system/docker.service.d/http-proxy.conf 编辑http-proxy.conf [Service] Environment="HTTP_PROXY=http://127.0.0.1:8888/" 然后重启服务： sudo systemctl daemon-reload sudo systemctl restart docker 测试是否设置成功： systemctl show --property=Environment docker 然后是登录docker login (registry name，对于官方dockerhub这里可省)，按提示输入用户名和密码。 当然市面上也有很多基于docker的免费或商用docker devops，如果上一步你选择了阿里开发中心的这些私有库，需要修改~/.docker/config.json到 /var/lib/faasd/.docker/config.json供接下来使用。 解决这二个问题后。基本可以往下了：mkdir test && cd test && faas-cli new onemanagerforopenfaas --lang dockerfile vi ./onemanagerforopenfaas.yml 在image路径前加上你的dockerhub用户名，或者把它改成完整地址（带registry。比如国内的阿里云docker仓库,记住版本最好要写上，不能用latest???）注意官方dockerpush支持private镜像，但是pull时会提示denied，所以不要把这个镜像设为private。(如果你使用官方dockerhub，且是private仓库，那么也需要~/.docker/config.json到 /var/lib/faasd/.docker/config.json，否则接下来通过faas-cli调用docker pull的时候会提示认证失败，push没问题，默认gateway127.0.0.1:8080需要一次faas-cli login --password xxx,自定义gateway的方法：dockerfile中gateway改且faas-cli login --password xxx --gateway配合改) 上面我们不用带语言的--lang php7（它是php72），是因为：虽然--lang dockerfile和--lang php7都会拉取一大堆template，但后者文件夹混乱。涉及到的修改需要在templates里进行，而前者涉及到的所有改动仅发生在一个文件夹，即生成的onemanagerforopenfaas这里。我们只需从template里复制一些关于php72的脚手架文件即可(index.php和functions文件夹)。不必修改template(也不要删掉，如果调用faas-cli xx -f ./xx.yml，它会再次自动下载)。 但我们这里不复制index.php和functions，把onemanager复制到生成的onemanagerforopenfaas根目录下，我这样做是为了不涉及太多的文件夹结构，也方便接下来的onemanager source（我使用的om版本依然是20200607-1856.19），因为它本身并没有使用类似如下的文件夹结构： 然后，对应修改onemanagerforopenfaas下的dockerfile（如果使用--lang php7要到template/php7下修改，十分混乱）： # Import function WORKDIR /home/app COPY ./ ./ WORKDIR /home/app dockerfile中有一处composer install由于被q也很费时。可修改dockerfile，禁掉composer install行，因为onemanager在vender中自带依赖，如果不禁掉，我们也可以在composer.json中自己手工添加下面chunks以提速(其实你也可以删掉composer.json，因为我们并没有使用到它)： "repositories": { "packagist": { "type": "composer", "url": "https://packagist.phpcomposer.com" } } 这样调试环境就建好了。调试过程就是修改源码（当然放在第二节中讲，这里是最主要的调试工作,这里仅关注流程），然后sudo faas-cli build -f ./onemanagerforopenfaas.yml && sudo faas-cli push -f ./onemanagerforopenfaas.yml && sudo faas-cli deploy -f ./onemanagerforopenfaas.yml。 下面仅给出结果，不给出具体的调试过程，但是要知道下面得出的结果是这里的不断调试过程得到的,所以这里的流程必不可少。输出信息你可以在源码index.php中写echo，可以观察8080 invoke按钮出来的信息，或网页直接展示。也可以journalctl查看。 源码修改： faas的那个web环境类似虚拟主机空间，所以主文件index.php中(这也是程序的入口)，我们去掉for tencent的main_handler和for aliyun的handler，直接： <?php error_reporting(E_ALL & ~E_NOTICE); include 'vendor/autoload.php'; include 'conststr.php'; include 'common.php'; include 'parsedown.php'; include 'platform/Normal.php'; $path = getpath(); $_GET = getGET(); $re = main($path); $sendHeaders = array(); foreach ($re['headers'] as $headerName => $headerVal) { header($headerName . ': ' . $headerVal, true); } http_response_code($re['statusCode']); echo $re['body']; 大部分需要调试的地方跟《利用onemanager配合公有云做站和nas（2）:在tcb上装om并使它变身实用做站版》一文一样，属于环境参数和path获取不到。 platform/normal.php中： function getpath() { $_SERVER['firstacceptlanguage'] = strtolower(splitfirst(splitfirst($_SERVER['HTTP_ACCEPT_LANGUAGE'],';')[0],',')[0]); if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR']; $_SERVER['base_path'] = path_format(substr($_SERVER['SCRIPT_NAME'], 0, -10) . '/'); $p = strpos($_SERVER["Http_Path"],'?'); if ($p>0) $path = substr($_SERVER["Http_Path"], 0, $p); else $path = $_SERVER["Http_Path"]; $path = path_format( substr($path, strlen($_SERVER['base_path'])) ); return substr($path, 1); // return spurlencode($path, '/'); } 以上注意到，faas使用的php-cli index.php唤起的服务。php72的$_SERVER数组中，并没有request_uri，但是完全可以用base_path代替。否则index.php中获取到的$path永远为空。这是由不同的web环境导致的问题。 另外一个需要修改的地方： function getConfig($str, $disktag = '') { global $InnerEnv; global $Base64Env; //include 'config.php'; //$s = file_get_contents('config.php'); $configs = '' ...... } 以上，我们把原本存在于config.php中的'{}'放到上面代替''，因为正常逻辑下程序不能获取到config.php，我们需要手动用《利用onemanager配合公有云做站和nas（2）:在tcb上装om并使它变身实用做站版》获到的envVariables并把参数给它。这样getConfig('timezone')这样的调用才能发挥作用。具体为什么获取不到config.php。。我也没有深入调试。应该也是openfaas所属特殊web环境导致的问题。 你可能还需要禁掉getGET()中的这段: if (!ConfigWriteable()) { $html .= getconstStr('MakesuerWriteable'); $title = 'Error'; return message($html, $title, 201); } 还有common.php中一些涉及到html输出的也给禁掉，以适应特殊的openfaas web环境。 突然想把git和docker弄成netdisk backend的静态仓库，不用做到git pull能git clone就好，因为它们的原理上，也是用curl来下载的。 发现一个v使用终端代理命令只在当前窗口生效的问题,如果执行./xx.sh是不能生效的此时开全局也无用，方法是要把该命令也写一次到./xx.sh中。 还有panel.sh缺少多租户环境的功能，对于openfaas是linkerd，我们知道，pai这种也是不支持多租户的，一次只能一个应用。多租对于个人用户也是有用的，那就是可以为每一个函数指定一个子域名并代理出去，目前openfaas使用/function/应用名的形式，可以寻求直接在主域上展示的方法。 还有那个顽固的dail tcp failed faasd-provider问题，日后也需要寻求解决 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
利用openfaas faasd在你的云主机上部署function serverless面板
本文关键字：自建云函数后端。self build serverless function as service,single node serverless 在前面《云主机上手动安装PAI面板》中我们讲到了在云主机上安装某种“类似baota xx语言项目管理器”的虚拟主机管理面板，也提到它并不是cloudbase版的云函数面板，后者这种方案要重得多： function serverless最初也是由一个专家一篇文章给的思路，然后业界觉得好用就流行起来了。vs 传统虚拟主机管理面板和language backend as service，它至少有下面几个显著的不同特点：1），它将服务托管细粒化到了语言单位，即函数调用，故名faas，2），它与流行的API分离前后端结合，对这种webappdev有支持3），它利用了devops docker, 可scaleable集群的部署。4）运营上它支持按需按调用计费，将语言按调用次数收费。5) 它面向来自内部外部多种不同服务交互的混合云，构成的API调用环境。 它自动化了好多部署和开发级的东西以devops，以容器为后端，Triggers是一个重要组件，从GATEWAY代理中提取函数。根据触发从容器中fork一个process出来（因此与那些纯k8s和swarm的管理面板直接提供docker级别的服务粒度不同）。这个process就是watchdog 它是一种similar to fastCGI/HTTP的轻量web服务器，提供函数服务。由于支持多种环境多种不同服务交互，因此main_handler()中总有event指定事件来源，支持event,content为参数的async函数书写方式（而这，是nodejs的语言支持精髓）。。 综上，它是某种更倾向于“云网站管理面板”的思路。and more ...开源界的对应产品就是openfaas这类。 openfaas一般使用到k8s这种比较重的多节点docker管理器。注重集群可伸缩的云函数商用服务。那么对于个人，只是拿来装个云主机搭个博客，不想用到服务端的云函数（虽然有免费额度，不过总担心超）的用户，有没有更轻量的方案呢？ 这就是faas containerd serverless without kubernetes:faasd，它其实也是一种openfaas的后端，只不过它使用containerd代替后端容器管理，因此它也可以To deploy embedded apps in IoT and edge use-cases，项目地址，http://github.com/openfaas/faasd/，作者甚至在树莓派上运行了它。 好了，下面在一台1h2g的云主机上来安装它，测试在ubuntu18.04下进行。 基础 以下脚本从项目的cloudinit.txt提取，有改正和修补。注意使用说明：外网访问云主机需开8080，如果提示Get http://faasd-provider:8081/ namespace=: dial tcp: i/o timeout之前，把你的云主机对外的8081打开，最好都打开。 一些变量 MIRROR_PATH="http://default-8g95m46n2bd18f80.service.tcloudbase.com/d/demos" # the openfaas backend OPENFAAS_PATH=${MIRROR_PATH}/faasd 安装依赖 apt-get install nginx golang python git runc python-certbot-nginx -qq -y 不安装runc会导致containerd可能出现oci runtime error，导致启不动faasd 安装faasd 1.3.5有个link错误，所以换用1.3.3。 # install faasd installOpenfaasd() { echo "=====================containerd install progress=======================" msg=$(wget -qO- ${OPENFAAS_PATH}/containerd/v1.3.3/containerd-1.3.3-linux-amd64.tar.gz > /tmp/containerd.tar.gz && tar -xvf /tmp/containerd.tar.gz -C /usr/local/bin/ --strip-components=1 cat << 'EOF' > /etc/systemd/system/containerd.service [Unit] Description=containerd container runtime Documentation=https://containerd.io After=network.target local-fs.target [Service] ExecStartPre=-/sbin/modprobe overlay ExecStart=/usr/local/bin/containerd Type=notify Delegate=yes KillMode=process Restart=always # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNPROC=infinity LimitCORE=infinity LimitNOFILE=1048576 # Comment TasksMax if your systemd version does not supports it. # Only systemd 226 and above support this version. TasksMax=infinity [Install] WantedBy=multi-user.target EOF systemctl daemon-reload && systemctl enable containerd systemctl start containerd 2>&1) status=$? updateProgress 50 "$msg" "$status" "containerd install" echo "=====================cni install progress=======================" msg=$(/sbin/sysctl -w net.ipv4.conf.all.forwarding=1 mkdir -p /opt/cni/bin wget -qO- ${OPENFAAS_PATH}/containernetworking/v0.8.5/cni-plugins-linux-amd64-v0.8.5.tgz > /tmp/cni-plugins-linux-amd64-v0.8.5.tgz && tar -xz /tmp/cni-plugins-linux-amd64-v0.8.5.tgz -C /opt/cni/bin 2>&1) status=$? updateProgress 60 "$msg" "$status" "cni install" echo "=====================faasd install progress(this may take long and finally fail due to network issues,you can manual fix later)=======================" msg=$(wget -qO- ${OPENFAAS_PATH}/openfaas/faasd/0.9.2/faasd > /usr/local/bin/faasd && chmod a+x /usr/local/bin/faasd export GOPATH=$HOME rm -rf /var/lib/faasd/secrets/basic-auth-password rm -rf /var/lib/faasd/secrets/basic-auth-user rm -rf $GOPATH/go/src/github.com/openfaas/faasd mkdir -p $GOPATH/go/src/github.com/openfaas/ cd $GOPATH/go/src/github.com/openfaas/ && git clone https://github.com/openfaas/faasd && cd faasd && git checkout 0.9.2 cd $GOPATH/go/src/github.com/openfaas/faasd/ && /usr/local/bin/faasd install sleep 60 && systemctl status -l containerd --no-pager journalctl -u faasd-provider --no-pager systemctl status -l faasd-provider --no-pager systemctl status -l faasd --no-pager 2>&1) status=$? updateProgress 90 "$msg" "$status" "faasd install" echo "=====================faas-cli install progress=======================" msg=$(wget -qO- ${OPENFAAS_PATH}/openfaas/faas-cli/0.12.9/faas-cli > /usr/local/bin/faas-cli && chmod a+x /usr/local/bin/faas-cli && ln -sf /usr/local/bin/faas-cli /usr/local/bin/faas sleep 5 && journalctl -u faasd --no-pager cat /var/lib/faasd/secrets/basic-auth-password | /usr/local/bin/faas-cli login --password-stdin 2>&1) status=$? updateProgress 100 "$msg" "$status" "faas-cli install" } 整个脚本跟pai安装脚本的风格很类似。可以像pai一样把nginx也整合起来作为总前端(openfaas+faasd也是前后端的一种说法)，把8080转发到nginx，要知道，nginx是通用协议转发器不只http，见《基于openresty前后端统一，生态共享的webstack实现》。 以上这些如果无误完成。在云主机上可以打开8080(faasd),8081(faasd-provider)等。打开8080需要登录。 如果打不开8080，可能是脚本faasd up时从docker.io下载的几个必要小images时timeout了。cd /var/lib/faasd/ && /usr/local/bin/faasd up（一定要观察看到几个小images下完，可能会提示8080已被占用）。重启即可访问8080。 在云主机上sudo cat /var/lib/faasd/secrets/basic-auth-password得到网关密码。用户名是admin，然后部署云函数：faas-cli store deploy figlet --env write_timeout=1s。系统可能依然会开二个实例，设成仅1个也可以。由于faas-cli都是一样的，其它相关适用的高级用法可以继续关注faasd相关文档得到。 然后，，，就是把运行在cloudbase的云函数移过来，可能需要一些补正，跑在自己的服务器上，好处是不用再担心额度了，省心省事。 不过说真的我对于这种docker做的虚拟化不放心，最好不要存数据。所以还是选择pai，未来整合pai,faas试试？ (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
在pai面板上devops部署static site
本文关键字：blog联合，一文多发，blog内容联合。headless ghost cms 前面《在云主机上手动安装腾讯PAI面板》中，我们发现PAI是一个利用git和devops，在仓库的根下放置.pai.yml来达到自动部署+运行APP目的的一种机制，除了没有容器和隔离，其它都这属于CD/CD的思路，下面来实际部署官方的hexo static blog例子，虽然我有点不承认它是serverless的hexo静态网站生成器（tx云函数官方也有一个staticsite版本，稍后会谈到真正的这类产品是headless ghost cms这种）但肯定比普通hexo要方便一点，完成之后的效果就是能作到类似利用git hook部署网站+自动更新（稍后也会谈到它的另外一个效果：可以与其它git仓库，如github,gitee作内容联合）。。 不废话了 安装hexo: 在管理面板中，我们要安装的是这个仓库，https://gitee.com/TencentCloudBase/pai-mate-hello-example-static，这个仓库是个hexo的example site项目，（正常安装后，会生成/data/pai_mate_workspaces/pai-mate-hello-example-static/pai-static-pages.js和/data/pai_mate_workspaces/pai-mate-hello-example-static/ecosystem.config.js，ecosystem.config.js是pm2用的守护脚本，它守护pai-static-pages.js开启3000端口上serving public dir的静态http服务，这个服务没开起来之前，访问与pai安装时的绑定域名会一直502，安装好后，可以访问域名），但是除了这些，它却没有安装好hexo本身（也许官方期待用户手动进服务器安装） 也就少了至关重要的hexo生成网页的作用，查看它的.pai.yml下，没有部署脚本deployScripts:，只有一行static: public（这正是上面二个生成文件生成的语句），---- 无论如何，这个仓库中的.pai.yml不完善。我们来完善补全这个仓库一下： .pai.yml，注释掉 static: public，另：不知为什么，hexoauto加--watch会与上一条冲突，导致3000频频挂掉，故 --name hexoauto后不加--watch # static: public deployScripts: start: - npm install - npm install --unsafe-perm=true --allow-root -g hexo-cli - npm audit fix - pm2 start -s ecosystem.config.js - pm2 start "hexo generate --watch" --name hexoauto restart: - hexo clean - hexo generate 手动在仓库里添加以上二个js文件，pai-static-pages.js: // This file is auto-generated by PAI-MATE const handler = require('serve-handler') const http = require('http') const server = http.createServer((request, response) => { return handler(request, response, {public: 'public'}) }) const port = +process.env.PORT server.listen(port, () => { console.log('Running at http://localhost:' + port) }) 手动在仓库里添加以上二个js文件，ecosystem.config.js // This file is auto-generated by PAI-MATE module.exports = { apps : [{ name: "pai-static-pages", script: "./pai-static-pages.js", watch: true, env: { "PORT": 3000, "NODE_ENV": "production", "NODE_PATH": "/usr/local/node/lib/node_modules", } }] } 这样部署后仓库就运行起来了，点管理面板中重启应用能达到最基本的自动部署仓库中的内容和启动静态网页服务的目的。只是，它缺少一个pm2 git clone。依赖手动重启restart处的hexo generate。整个应用处，还是需要一道工序（而理想状态下，内容源git一下应该是唯一的工作）。 内容联合： 曾经我们有网盘联合，内容转存。blog和文章作为一种“内容”，有时也需要联合和一文多发。这类功能应该加到各大笔记和知识库核心功能中，当然也有这样的独立产品如artpub。 上面的git方式联合，只是让仓库和这个静态站之间作内容源联合。这种基于git devops的工具层的东西，在内容联合方面还是有局限的。 在多样内容源联合方案的选择上，还是基于API的好（因为可编程的东西不局限于工具，见《用开发tcpip的方式开发web》），比如那种headless ghost cms content api+JAMstack front-end like hexo的方案就好多了(这也使得hexo这类工具通用BLOG静态生成器上升为通用网站生成器的境界)，在“迁移内容”，和”换前端“方面都有很大的自由度（虽然费折腾但是做成工具和产品也一样）。 下文，由于pai是个类似baota panel基于pyenv的python项目管理器，下文探索它的py项目部分，未来讨论利用staticsite和markdown生成整站单页pdf book等课题 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
rcore,zcore,兼谈fuchsia:一种快速编程教学系统和rust编程语言快速学习项目
本文关键字：一种快速编程教学系统和编程语言设想,把devops和hypersior集成到os和app,learn rust:the hard way笨方法学rust 在前面《云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想》和《一种设想：为linux建立一个微内核,融合OS内核与语言runtime设想》中，我们都讲到“语言机制与OS机制一一对应的运行时”的思想，这些属于平台与语言连接处的联系对于编程学习至关重要，直接影响着你在这个OS上学LANG写APPDEV的曲线，（正如“业务逻辑与APP编程”处的连接一样（《一种开发发布合一，语言问题合一的shell programming式应用开发设想》一文，业务逻辑如果采用尽量接近平台的某种逻辑，也会变得相对容易，这是后话，目前，我们仅关注前半句），这种思想得以最大体现的二个地方，一是发明一个OS，二是学习一个语言。 rcore,zcore： 拿发明OS来说，实际上oskernel作为对裸机编程的典范，也需要极高的抽象，内核的发明是一个重写语言的过程（这种工作却没有被用户空间的语言继续下来），采用什么样的语言来写内核，决定了工程的难易度，甚至直接决定最终设计，(比如windows在kernel中实现了一个对象系统，它是用C模拟的是在发明reimplent c，，如果采用的语言抽象层次高，这类事情成本就低，）比如，采用rust，它抽象高,batteryincluded，写出的应用代码量就小。甚至可以拉高抽象决定设计，做出language based os:一种general kernel design using language-based protection instead of hardware protection，libos。 rCore是c版本的清华大学教学操作系统uCore(u:micro)的Rust移植版本,它里面的syscalls是兼容linux的，可以运行userspace的linux用户程序，后来，他们参考rust-osdev.com织织的成果，将整个rcore又重写为zcore，以接近fuchsia使用的zircon微内核，（Fuchsia 是谷歌试图使用单一操作系统去统一整个生态圈的一种尝试，类似华为的多场景OS鸿蒙），这种微内核特征在《一种设想：为linux建立一个微内核,融合OS内核与语言runtime设想》已经说过：拉高抽象结构，将被兼容内核放在下层用户进程级，这其实就是wsl1等 os subsystem的套路，也是libos，“一个进程一个OS”的思想，以及language based os。 目前为止，它们的代码http://github.com/rcore-os/中，有很多子项目(rboot,rcore-user,etc..)，最重要的当然是http://github.com/rcore-os/zCore，它重写了rcore为微内核zircon-object(包含内存管理和任务管理二部分)，有兼容以前rcore的linux-object和linux-syscalls,linux-loader，还增加了对fuchsia的zircon-object（除内存管理和任务管理的其它部分)和zircon-syscalls,zircon-loader。作为最终结果的zcore，可在unix(linux/macos)下以libos方式运行linux(make rootfs,cargo run --release -p linux-loader /bin/busybox)和fuchsia的程序(cargo run --release -p zircon-loader prebuilt/zircon/x64)。也可bearmetal以独立qemu运行(make image,cd zCore && make run mode=release linux=1,cd zCore && make run mode=release)。如果不好理解，你可以把整个项目成果想象成拥有wsl1 subsystem和win子系统的win10(wsl2改为更按近vm的实现方式)。 编译时，rust源码编译跟cpp一样慢，这是真的（不过想象其运行期安全和抽象在运行期0成本就忍了）。下载大量crates时。记得把register设为ustc的源。不过，我编译上述项目时，在osx14下运行cargo run --release -p zircon-loader prebuilt/zircon/x64和时cd zCore && make run mode=release都有失败。 以上都不是重点，这里才是：在重写zcore的过程中，他们发现fuchsia的微内核中的系统跟rust语言的很多机制紧密对应（非精确一一对应）。----- 除了他们的V3 rev文档库https://github.com/rcore-os/rCore-Tutorial中将这些开发过程都详尽写出来了，在https://rucore.gitbook.io/rust-os-docs/也有一篇《Rust语言速成》还提到，快速学rust最好的办法是发明一个rust os，顺便与C的交互也学习，探索高级语言的局限（而这在以前的c语言+linux这类教育中是不太可能的，因为前者抽象不高涵盖不了语言学习的典型场景而后者也不能）。。。 fuchsia其它特点: 继《一种设想：为linux建立一个微内核,融合OS内核与语言runtime设想》我们还发现了fuchsia中的其它特色。 zircon内核实现里有个虚拟机管理器：virtual app有时称为guest app，这一再印证，从《hyperkit:一个full codeable,full dev support的devops及cloud appmodel》一直写到这的“碎片化app，microapp，微内核OS，碎片化os，virtualapp”也正是zircon要集成到内核中的方案，记得华为的鸿蒙是“全场景分布式”，而最终，各种沙盒各种层次的虚拟化不就是为了使开发系统和部署APP结合，而且能做到更分布更细粒吗。只有细化才能分布式。 如果说云计算无O也就无APP，或许最接近原生的分布式APP：要算这种micro virtual app吧。----- 而其实统一语言，和统一内核，都是为了让真正的applvl的virtualapp出现。不过业界早有docker这样的暂代方案出现。 第二： Zircon 上的一层名叫 Garnet。 Garnet 包含Xi Core，the Xi Core engine for the Xi text and code editor. 它是Xi文本和代码编辑器的底层引擎，在系统中集成IDE，是为了降低可视调试难度。这接上了我《jupyter:devops tool with visual debug》《elmlang》的“开发要接上系统，集成在系统内部以降低难度，devops与rad结合”那些观点。 第三：zircon的flutter层面。这种用web前端技术完成的app ui，如果有了wasm的加持，可以出现在系统的各个层面，不光是web browser内。如果browser都虚拟化了，碎片化了。那么整个cli都是可以web方式开发的，共享统一appstack开发结构(一种ui决定一种app)。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
一种设想：为linux建立一个微内核,融合OS内核与语言runtime设想
本文关键字：os之争。微内核,language based os,language on bearmetal not on os，华为鸿蒙，语言即OS，类脚本语言，把原生应用变语言模块。 我们知道，OS兼容跟语言兼容一样，是一项几乎不太可能完成的事情，因为OS的使命就是作为闭环竞争的商业产品出现，成就造出它他们的公司。从文件系统的多样化和存在的互访鸿沟就知道，见《一个设想：基于colinux，去厚重虚拟化，共盘直接文件系统安装运行的windows,linux》。osx有apfs,windows有ntfs，linux有btrfs/ext，难得出一个exfat，又仅是作为数据盘存储格式不能作为系统区存在而且也有坑（不过也听说过在exfat上成功装系统的）。os之争与语言之争一样，技术上不是不可能融合，而是厂商各自为政。不想那么去做。 但幸运的是，软件是抽象的堆栈，业界方面这些融合一直在进行，只是比较缓慢。融合可以从源头(对于os是kernel)完成，还可以在别的层次完成，类似《编程语言选型之技法融合，与领域融合的那些套路》谈到的那些语言融合。 OS/OS内核/OS的融合经过了很多发展阶和变形形式，如日常我们使用的PD,VB虚拟机管理器里的os，wsl( as os subsystem)，虚拟机管理器on baremetal(qubeos,etc..)，虚拟firmware内嵌虚拟机管理器，os级的虚拟化openvz，简单的chroot沙盒os，iaas大数据级别的kvm，最后，就是这篇文章要谈到的：从0开始，和从os kernel源头进行融合OS和语言系统的os。即“微内核+unikernel”。 OS的融合其实和语言/语言runtime的融合其实可以是一个相关的过程，如《基于colinux的metaos for realhw，langsys和一体user mode xaas》如《一个隔开hal与langsys，用户态专用OS的设想》中关于让os的子系统直接服务于语言runtime的思想。我们在《云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想》中也讲到语言的后端和容器和OS的关系(通用容器和语言虚拟机/语言沙盒/baas/serverless，这些东西的存在，其实是”可移殖可隔离runtime“的功能重合。正是面向不同方向但同一目的的某些意义上的“重造轮子”。) 安全的内核级语言：unikernel化 os与语言的关系从来不是先有蛋还是先有鸡，而是先有蛋（语言），再有OS（鸡），自举语言和自举OS特殊情况另当别论，历史上和我们现实中出现过的常见OS，其kernel都是C开发的（我仅指osx,linux,windows kernel），，c runtime作为toolchain系统实现层面存在。c库存在用户空间和程序空间的部分是有特权不同的，它们之间要跨syscall互访。应用开发层次的语言系统处在用户空间(由此,官方py版本这种语言是不可能作内核编程的，抽象层次太高运行时也巨大)。我们把内核中的c称为“bearmetal或toolchain”语言，因为它们最开始的作用是给硬件平台提供软件管理层的作用。 由于语言放在OS之前设计（没办法，先得用起来，那个时候还没有出现既能保证开发效率运行效率又能保证安全的语言如rust），架构于os kernel之上。于是kernel的二大机制（内存管理和任务进程）会继承C语言的固有缺点，比如运行在这种OS上的程序会发生内存泄漏，这对于系统实现和APPDEV级都是延续的影响。我们现在的OS，如果它们自我宣称它们是“安全的OS”，其实是某些高阶层次的完全，比如OS应用方面的安全。并不是“内存管理和任务进程”方面的绝对安全。运行在这种OS上的APP还是会发生内存泄漏，因为“程序申请内存”这个功能，无论处在编程的哪个层次，都是从OS继承的能力（任何编程都是某种意义上的系统编程）。GC只是自动释放并不能改变OS内核这种可能的缺陷（这只是一种可能，OS内核的质量会保证这种情况很少出现）。 那么，为什么不采用一种从一开始就足够安全的bearmetal语言呢，如rust？ 当然可以，语言放在OS之前设计可以直接省掉OS发明的很多问题，如cpu的保护模式甚至都可以略去，特权模式无关紧要，一种内核天然是bearmetal和usermode通用的（驱动和hal层放在用户空间）。你甚至还可以将rust的stdlib整个实现在bearmetal层,使得内核编程跟系统开发编程/系统应用编程共享同一门语言。 这些特点加起来，可以直接用语言作为虚拟机管理器（这种语言系统和OS最绝佳的关系，正是另一种os kernel-libos的特点：它可作为lib的os被嵌入语言使用，用户态无须经过虚拟机管理器。直接为支持“一app一os”而提出的os）。因为你可以把语言系统作为OS的源。直接compile and run一个kernel出来，使得语言架构于OS之上，做成devable os。在《云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想》中我们提到unikernel是docker等lanauge runtime的代替品。这里是“more safer unikernel”。 当然，为促成microkernel+unikernel，这还需要一些额外工作。比如，将这种内核裁剪下，去掉“不那么重要的部分”。 采用了安全的语言，我们还要给内核“微内核化” 首先，这种内核要小。仅保留必要的“内存管理和任务管理”。如上，我们知道，内核中最关键的是“内存管理和进程管理”,因为这二个部件，足够可以运行某种“APP”(内存和并发，刚好它们也是语言runtime的重大问题之一，所以这里“语言runtime即OS，这种特征又一次出现了”），除此之外都是addon,非essential的。hal,drives，文件系统,gui都是第二级别的。我们可以把这种OS的“驱动”保障效率的前提下放在user space（如上，实际上，这种OS kernel下，没有内核空间和用户空间的区分了）。传统上，我们将hal和driver一部分放在(firmware或boot层)，一部分放在os kernel层。 这就是微内核。OS层的其它组件可以通过ipc通讯放到其它具体os kernel下，它本身可以很小（作为meta os kernel与其它内核合作，管理这些内核并融入这些内核,这也使这些内核可以实现真正的跨OS）。比如给linux kernel,这种monolitch一体化宏内核作上层，复用它里面的东西。 综合上的microkernel和unikernel，如果融入现在的linux，比"用虚拟firmware内嵌虚拟机管理器打造applevel虚拟化的容器和开发方案"这样的办法要强多了。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
我为什么选择rust
本文关键字：allinone编程语言，个人是否真的可能学好多门编程语言 我们在前面《编程语言选型通史：快速整合产生的断层》提到,我们需要一门"简单，oneforall"显得不那么“断层”的语言来工作和学习，以积累自己的codebase和开发经验而无需推倒重来或切换，---- 这个问题之所以重要和紧迫，如上文所讲，是因为编程语言一直处在开发和学习的中心，占据一个程序员的大部分时间和心智精力，语言选型必须先于其它进行。而现实情况是，技术总在演变，而融合正处在初级阶段，人们在学习和工作中总涉及到使用多门语言的情景，产生的断层和学习成本巨大(见《qtcling - 一种更好的C++和标准库》和《编程语言选型之技法融合，与领域融合的那些套路》) "程序员总是需要不停学习"，。这个时候，我们希望获得一种简单，但allinone的语言和一劳永逸的开发领域研究对象。对于出现的新开发，也可以以自然不虐心的方式融入，共享同一套生态，---- 俗语，用一种语言解决所有问题。这个问题放在10年前是不可能讨论的，但现在可以了。 “任何编程语言都一样麻烦”,软件无银弹，排除这些同质部分。来设想一下，对这种语言最基本的要求，首先是要保证简单，避免CPP那种越做越复杂带来的坑。不要求它有对低阶语言有很好的源码兼容性，但至少要能接上现今二大生态（naitve/web）。语言写法上的限制和自由是一对矛盾，这个时候我们宁愿入门前曲线陡峭，入门后一马平川，除此之外，它还应绝对安全（非必要不写unsafe），是运行期免错的语言。 对于符合上述要求，现今为止能很好作到“allinone”写法的语言和跨embeded/native/web/mobile(甚至web前端)开发的语言。Dlang/go/rust是唯三的选型对象，这其中，rust是最全面的。从语言演变历史中那些坑中综合排查，这点上，因为rust出现得晚，取长补短，rust没有任何包袱。它是最不虐心的。rust源于cyclone的部分概念，虽然说这些cpp的新版本也能做到，但cpp应该改无可改面目全非了，不如一门新语言来得更让人易接受。 具体来看rust的优缺点： 它有： 1，它涵盖toolchain即appdev领域,是真正的通用语言,着眼现在面向未来 它支持跨embeded/native/web/mobile(甚至web前端)开发，而其它不少语言也宣称它们通用，但总是存在大量的坑（比如人们不常用php-cli，仅用php-cgi）。rust没有这些包袱，是真正的通用语言,即又具备动态和脚本语言的写法和效率，而且又以一种自然科学不虐心的方式进行。而且它的微运行时能嵌入browser，着眼未来wasm技术。它也能被很好用于未来的AI，因为安全和效率比py高。 2，它涵盖现在的主要语言体系，聪明地定位于安全的编译型语言。 如在静态语言中谋求动态，如let,又将以前仅运行期能做的。用模板和泛型可以完全弄到编译期，如整套的编译期内省。达到了现在流行的静态/动态/语言脚本语言都能拥有的效果，支持脚本语言的逻辑热更。上面谈到，它是强编译期安全性的，能保证运行期免错（解决了c增强系如CPP的痛点：内存泄漏和数据竞态）。其实运行期与编译期只有二个期的不同（对导致语言灵活和动态性差别没有本质联系）。不一定语言的动态性就一定要体现在运行期。编译期可以让语言达到足够的动态性，这就是动态编译。 3，它涵盖了所有语言技术,建立了所有语言的多范式超集，具备了流行的开发支持， 见《编程语言选型之技法融合，与领域融合的那些套路》，现在所有的语言，基本不是函数式（这类语言的代表就是lisp,haskell）就是过程和OO式(cpp,java)或者它们的综合(py,js,go,rust)，都可归为这二种流派。其实现都是对他们的简化与修正。而rust对这二种流派都有全面吸收和支持。 4，它不复杂，为了融合和发展，它另辟创新，解决了C增强系的痛点，而没有提出过多的新概念，甚至没有GC 拿cpp与rust这些“增强C系语言”对比，我们要忽略cpp对c的源码兼容是c的增强（严格来说，cpp应该向它的祖先cfront靠拢以增强C。）这层极具混淆性的意义来说，把cpp与c看成是一高阶一低阶的不同语言，这样我们就能方便地拿出两者都提出一门高于c的新语言的起点性工作开始对比：它们都保留指针和控制底层的能力，但rust有引用和借用,类型所有权，，极其聪明地（虽然有些强制和面向契约）规避了cpp的坑,同样没有GC，同样用raii却避免了CPP的内存不安全。 与dlang/go这样的“简化C系/cpp语言类”比较，达到同样的效果却而避免给语言增加gc这样的乱入式大部头。一门语言集不集成GC，这是影响到语言本质的问题，比如go集成GC，其运行时会比rust大好几个数量级,rust极小运行时。这对嵌入硬件平台和嵌入WEB浏览器极为关键。它对glibc这样的东西几乎无依赖。。 对语言的学习，从对比它们的类型系统，作用域，支持的高级数据结构，异常，。。。。这些层面，基本一个认真学过几门流行语言的人都可以在10小时之内了解完。（引用，借用，其实并没有给rust新增加多少东西，其它都是向简集成） 5，它兼顾了现在，也能接入既有多种生态和未来扩展方向： 它能生成对c的转译结果（接上了系统实现和系统开发生态），以及对js的转译结果（接上了web前后端生态），而现在转译式开发是很流行的。place rust on top of c and js（比如 c,js作为低阶语言仅具备基本的过程和函数，oo和高级函数语法放在高阶语言rust层），这是很well arranged的。 对于未来，它也有考虑，如wasm，如virtual appliance，见《云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想》，未来应该是libos,unikernel,Fuchsia os这类可编程可devops可嵌入可物联的内核的天下。 它没有下面这些，但不重要 （一个事物的优点的这个说法，正是它缺点的某些方面，在一定的可讨论范围内，任何选型都是一对矛盾）： 它没有对C的源码兼容支持它没有GC。这刚好成全4，5 它没有过于简单的语法。但其实这是个仁者见仁智者见智的问题。（引用，借用，这些是rust最本质的创新） 它没有显式的语言层DSL支持，但它内外部已集成足够可用的东西。见3，5 它没有统一后端，但有 C ABI 二进制兼容对外interoperability能力也好。，也没有类elm的interoperability to js，见5 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
编程语言选型之技法融合，与领域融合的那些套路
本文关键字：oneforall 编程语言真的存在吗，多语言统一学习法，统一native/web语言和领域,the web api/service and serverside/cliside web programming essentials 在以前的文章《语言选型通史：快速整合产生的断层》中，我们一直讨论one for all编程语言，开发是一个四栈（语言系统，平台，人，问题/应用）的综合过程，因此对语言的讨论涉及到这四者的边界，只能综合而论。本文档集也一直在探索一种自然不断层方式的native/web，本地/分布APP统一的语言系统和编程模型(其它三栈我们统一称为为appstack/appmodel编程模型，因为它是被开发的主要对象，和语言要处理的目标体)。业界从来都是“先用起来再融合”原则，这使得新旧语言和编程appstack层出不穷。支流分分合合，语言系统在融合appmodel也在融合。事实上，我们开发本来就需要多门语言综合，但业界显然也在探求语言融合之道，先来说语言的融合，它主要分为二部分： 语言技法的融合：语言内的DSL化方向融合 （1）首先是统一前端语言，这是主要的融合方向，我们知道，代表一种语言本身最具辨识度的就是它的写法，也就是技法。新语言都是技法融合的代表，兼容(源码或者api/abi二进制发布级)和多范依然是语言内融合的主要手段，如cpp融合c,go融合lua,rust融合c/cpp，只是，在处理工业需求和学习曲线上，CPP的多范型固然没错，就是复杂化的痕迹很明显。所以会有go这样的语言来简化。这样的结果是出现了多种语言前端和后端组成的语言生态系统（注意这四字，语言从来处在其它三栈的边界，所以是一个生态的一部分,比如pme适合GUI，async适合分布异步，微后端化可以被用于嵌入编程，而唯有C系才能进入系统内核编程:内核空间与用户空间的编程环境非常不一样只支持C语言这就将任何基于脚本的原型语言和设计排除在外。静态编译类语言安全，而解释脚本类开发时效率高但不安全不能用于高精密领域，语言的逻辑热更新，编译型语言也能办到，这与语言是什么属性毫无必然关系，------ 这些都是语言与其它三栈无层次联系的几个例子，代表了它们的适用领域和人群需求，发明初衷） （2）另一种方向是统一后端，如jvm体系，clr体系，各种技法和语言前端也被分散在了前端语言中，如jvm上不但有java也有jpython，clr上也有多种语言，这种统一后端方向的融合工作也没错。相比统一后端，统一前端要复杂得多才是真本事，真根本。这样的结果是仅出现多种语言，但是生态得到了极大简化（比如问题域统一/库抽象比较统一可以多语言共享）。 这二种融合方向，其实都基于一种最基本的事实和本质：随着新出现的业务需求和人的要求，任何语言都需要不断DSL化。而任何语言，它们的内部和外部扩展能力。都是这门语言出生时的“最小使命”，来归纳一下现今现语言的元编程能力： ps: dsl化方向的融合： 语言系统最小应该提供什么，然后才是其它什么东西？即自我扩展的能力：DSL能力和元编程设施如CPP有范型，这种参数化类型成就的泛型和元编程，这使得CPP可以在编译期仅靠语言本身技法就可以实现DSL，辅助程序员完成“库是用来扩展语言的这种说法，但更重要的是需要语言本身也可以扩展自己”，另外二个运行期语言系统的对比，就是js和py了。js可以在语法技上用函数机制直接在抽象ast上写程序（任何语言机制都可以用函数抽象达成，而且这种抽象受语言核心支持,都可变成一级对象）具备元语言能力。而py可以用“meta object”之类的语言级抽象来提供元语言能力，辅助程序员完成“库是用来扩展语言的这种说法语言自身也可以”，后二者在运行期追求语言结构的变化（比如内省，这对GUIprogramming抽象亲和但不够安全），提供灵活性，但有得有失，不够安全也增加了运行期的维护调试成本。这是 cpp/rust vs js,py这二门派语言在借助编译器提供DSL能力上的显式区别。------ 否则。为了完成以上目的，语言需要提供显式化的“用语言本身来发明语言”，需要使得语言本身被服务化，可以被作为库调用。比如像terralang,racket-lang（A programmable programming language，language oriented programming language）。这种显式宣称自己有DSL能力的语言。---- 但是它们将这种能力放到了语言设施外。 但是，无论如何，上面的任何一种，都是”语言系统“级别的融合，其实这都使得语言学习成本增多。没有统一学习法,一门语言应该核心稳定，为了长久的应用或学习曲线，，，但是开头说了，业界从来都是先把想到好用的先用起来，再慢慢解决不那么重要的麻烦事。即融合使之进入同一个生态更好用。 那么能不能改变开发中的其它三栈行为，使得语言跨域实现oneforall呢（如同上面的lang本身DSL化一样）？ appmodel融合：语言外对语言融合的要求与实现 业界终于想到对融合APPMODEL下手了。这就是上面不那么重要的麻烦事之一。 我们知道，到现在为止，我们的常见领域主要有欠入式os实现类/native/web领域，语言都宣称它们是通用类，但实际上都被设计成领域实用和领域适用。现实中语言无论上面提到的哪一种，其实都可以DSL无限化，但都是在一种语言生态内完成的都不能跨应用域，那么有没有真正跨域的语言呢，实现语言真正的one for all？比如最难攻克的native/web融合.... 分布式应用现在最典型的就是web，很难为分布式框定APPMODEL，因为这是一种跨OS跨进程的“APP”，---- 分布，是一种产品分离，也是抽象的一种，同时关乎产品设计和语言程序设计，可以用多种方法来达成。web就是一种。但是这种领域不能做本地计算密集的游戏应用。而且要求的语言跟nativedev大相径庭，那么有没有让他们共享同一种语言系统呢？ PS：the web api/service and serverside/cliside web programming essentials web作为业界分布式程序的第一种广为流传的尝试和成功案例，其实它带来的误导性和建设性(支持页面链接，碎片化程序发布即page app)一样多，web误导了真正的分布式很多年。使得plan9和x11这类原生分布式都失败，单就其bs web技术选型中的浏览器技术，基本用可编程的clientside UI(js->page)代替了app ui，一条道走到黑。先不说这个， 现在的web/webstack技术中，服务端的主要任务主要集中在MVC框架内的东西，即数据方面orm协议方面url regex route/request/respone模板template filter，包括了部分客户端逻辑,这部分客户端逻辑可以完全交给客户端来做。服务端即MC。客服之间交互的，或者是request/respone这种传统带状态的协议，或者post json作为请求的webapi。至于客户端方面，就是一个可编程的v8 render,。web编程的协议本质是对request/respon编程，所以这是客户端和服务端共同的，客户端还主要负责DOM编程（以后扩展的webcliside技术还有很多~~）,，有jquery,pwa,react,ajax这些客户端技术来与服务端的api交互。综合完成webapp的效果（会前后端开发的叫全栈）。我们讨论的就是这种前后端分离的web编程。区别于传统页面跳转无状态的方式。-—— 这种api和面向微服务的web开发特征是：将gui分离出去。web就有了类native的appstack和mvc,,前后端分离，仅靠一条api地址和参数交互，就分离了本地和分布式最根本的问题。各具体组成栈最大解偶，任何app，不要把gui作为框架和app栈的一部分。后端只需负责services。把写业务，和写界面的语言和生态分开。 对于可编程的web的要求，是为其装配某种web可用的语言件api供人们使用,这样才能接上语言和开发，而web是现在唯一的真正的跨端跨OS跨设备跨语言的编程模型和appstack，这也是它API方面的要求：历史上，这些web api,web service技术其实很早就出现，最初它们是在本地做的，为了达到分布式跨一切的效果，以前是利用各种rpc/rmi技术规范给本地语言导出的web函数建一个调用方的本地桩，使之分布式和组件化，这种rpc webservice越做越复杂就淘汰了，因为脚本语言出现了带来了源码即组件的概念：即通过虚拟机语言往往是跨平台的特性，一方面使得web服务本身并没有任何来自OS的载体webapi纯粹脱离本地平台化API，，另一方面分布式要求开发件和发布件一体，脚本语言刚好src api即web runtime一体，在编程上可作为虚拟机语言的脚本源码组件代替传统API桩的作用，而所谓API桩 ---- 其作用相当于一种语言或平台port给另一种语言或平台的代理和转接逻辑，为了API而设的wrapper api，一个类比例子是软件方面的桩，如x11server，它实质是部署在客户端的server。真正在服务端的是显示服务器,所以这种x11 remote app本质也是一种分布GUI的APP（跟webbrower一样），plan9的分布FS协议也是，而我们传统的WEB是另起灶炉设计的，这就是我们第一句话讲到的web的误导作用，误导了真正的在OS级直接提供原生分布式服务的架构发展，曾经为了web跟nativeapp接近搞出了ajax,websocket,wetbgl，好了不说它了，都是泪。 这就是说，web开发和nativedev天然断层，完全不搭。下面是业界对他们的融合之法： 为了达到使用同一语言能领域开发融合，需要针对appmodel栈中的平台，应用规范，整合具体语言针对的领域。或者作广泛意义上的appmodel融合。 （1） 作为融合能多领域开发的语言的例子，业界能做到这点的唯二的二种是go和rust： 比如对于跨web,native的开发，可以不改造既存语言和它们的生态，却综合它们的生态，也使语言建立层次。就如同c之于汇编一样，使新语言提升到高阶。比如，正如c是汇编的高级语言，rust是c/javascript的高级语言（视c/js为高级汇编,c,js都是基础语言代表二个平台。而go,rust这类都是主语言），rust/go是可以转译到低级语言javascript或c的。现在这种转译语言语言还非常流行，比如typescript可以转译到js,elixer可以转到haskell.这样就统一了语言针对的领域。 （2）为了进一步统一native/web，于是就有了emscripten和asm.js这种东西（在浏览器沙盒中甚至都可以运行linux，和qemu虚拟机，当然这些目前都是实验性质的）。再来看wasm，WebAssembly 不仅可以运行在浏览器上，也可以运行在 非web环境下。非Web环境可能包括JavaScript虚拟机（例如 node.js）。但是，WebAssembly 也被设计为能够在没有 JavaScript 虚拟机的情况下运行。这基本是浏览器中搞nativeapp，而且绕一层js，它还有一个意义：让前端支持cpp等语言，使js不再是前端唯一语言。只不过目前wasm仅是用来辅助js的一个扩展，而业界甚至也搞出了纯wasm的前端. 以上这2点，类似语言的DSL融合合，但又是关乎appmodel融合的。其实都是最终appmodel对语言要求的侧影。因为开头就说过，语言会提供什么技法，都可以被归结为“语言技法与问题域结合处的那些东西，要求语言提供某些特定的习惯用法与设计模式：如frp,pme能很好GUI和异步，mvc能很好处理WEB框架”，语言技法和领域都会让语言呈现变化一样。 下一文《盘点语言技法与问题域结合处的那些习惯用法与设计模式1，2，3》 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
利用fodi给onemanager前后端分离(2):测试json
本文关键字:利用onemanager给fodi做php后端 在前面《利用fodi给onemanager前后端分离1》中我们介绍了在cloudbase上安装fodi py后端的方法，这里继续尝试将om作为fodi的后端也尝试弄上。 这里要说个历史，fodi的作者也是参考了onemanager的,精简的onemanager流程就是fodi backend那些(https://github.com/qkqpttgf/OneDrive_SCF即是那个最简的php后端)。别看onemanager比fodi体量比fodi大，它其实后端就二主体逻辑文件。platform/TencentSCF.php和index.php(转common.php)，一个是处理scf的，一个实际上是将od api结果转换成om api结果并渲染的结果。我们的目的非常明确：om最终返回一个网页html，onemanger混合了前端在输出结果里。作为一次api response，所以我们需要给它前后分离一下。让它返回正常的类fodi后端的json结果，而不是post render过的html，然后考虑对接到fodi前端。 纯 api 服务器:基础工作 所幸虽然onemanager本身是客服输出合体的，但内部也是细分到不同函数的易区分，客服也进行了区分。这使得我们的工作较为容易进行：我的版本是https://github.com/qkqpttgf/OneManager-php/commite439ed8e68c4ae0d8d42bc5c293a3ba06aa1bc9c，20200607-1856.19，主线逻辑：main()->list_files->files_json(),or render_list()，分解重要的函数或逻辑有二支：（1）list_files($path)->fetch_files($path)，（2）render_list($path = '', $files = '')->fetch_files($path)->output，renderlist就是客户端输出逻辑。onemanger支持https://www.xxxx.com/?json的调用，这个函数就是common中的function files_json($files)，会输出json，相当于在fodi后端index.js中?path输出json那些逻辑。接下来的工作就是这二个函数的处理。 我们的测试环境是在一台VPS中(对应platform/normal)进行，我是在宝塔面板中完成的，分成二个网站部署好om代码和fodi frontend。然后fodi原来的后端我是在cloudflare中开免费worker搭建的。fodi front复制成二份html放在第二个站下，我们的思路是比对这二套系统的前后端，以促成我们的目标。事先在文件夹中放一些文件，还有一些准备工作： om需要预处一下：服务端index.php顶层代码块（这里并没有处在一个函数中）中： } else { include 'platform/Normal.php'; //从这句开始改 //$path = getpath(); 注释掉 $_GET = getGET()后面加一条： $path = $_GET['path']; //$_GET是收集到的用户输入的参数组成的数组，该getGet()在platform/normal.php下，这里是得到path项,这样，用户在浏览器中输入什么网址(http://apiurl/?path+参数)，就会展示该路径下的json结果 服务端common.php这个三合一平台通用接下来逻辑中，main($path)函数中： if ( isset($files['folder']) || isset($files['file']) ) { return render_list($path, $files); //原来的带完整html输出的注释掉，换成接下来这句 return files_json(/*$path, */$files); function files_json($files)函数末尾： return output(json_encode($tmp)); return output(json_encode($tmp), 200, ['Content-Type' => 'application/json']); //这条实际上在新版被修复了 客户端fodi那个frontend html中：要将/fodi/去掉或模拟出来 window.GLOBAL_CONFIG = { SCF_GATEWAY: "https://apiurl/", //这里你也可以用https://apiurl/?json如果上面你没有把render_list改成files_json SITE_NAME: "FODI", IS_CF: true }; if (window.GLOBAL_CONFIG.SCF_GATEWAY.indexOf('workers') === -1) { window.GLOBAL_CONFIG.SCF_GATEWAY += '/'; //window.GLOBAL_CONFIG.SCF_GATEWAY += '/fodi/';改成/ window.GLOBAL_CONFIG.IS_CF = false; } 在宝塔服务端网站的设置->配置文件中，加好ssl，并把web安全域名设置一下，否则接下来chrome f12调试会产生跨域错误（cloudflare没有这个问题）。chrome这东西不光是web browser，也是webdever的IDE加调试器，其实这个也可以在程序逻辑中设置，但比较麻烦。 for nginx: server块location下，直接放在伪静态里也可以 add_header 'Access-Control-Allow-Origin' '*'; for apache: </Directory> Header set Access-Control-Allow-Origin "*" </VirtualHost> 然后就可以接下来调试了(注意不要用safari尽量用最新的google chrome，支持度足够，macos big sur之后的safari才能返回正确结果)，调试程序最难的是找到调试的方法，以上这些都可以在chrome的f12，network->request,respone中看到，否则还是chrome f12产生错误，对于后端，你加入的调试只能在云函数执后台看到，对于前端，在chrome中查看。要区分哪些?path是服务端测试调用的，哪些是客户端的。 纯 api 服务器:调试工作 在fodi构造https://apiurl/?path=%2Fd%2Fmirrors之类的url（%2F是/），比对cf和php后端观察到输出的结果。结果是都不会变的。喂给fodi的?path=返回结果不会变的，因为它是接受json请求的而不是GET形式的?path。喂给php端的需要再处理一下。 这是om输出的： {"list":[ {"type":1,"id":"01AL5B7D25YGLLNRUY5FG3INXIYG5BDB5V","name":"d","time":"2020-07-23T14:14:52Z","size":14716769375,"mime":null}, {"type":1,"id":"01AL5B7D26ZI4V2QKN35HJSUUZPTHQ3KQN","name":"docs","time":"2020-08-02T05:59:38Z","size":5640494,"mime":null}, {"type":0,"url":"https:\/\/balala...","id":"01AL5B7DY3H337ZRZ3BNAIUSPVR5RXLU2M","name":"readme.md","time":"2020-08-05T12:25:06Z","size":1311,"mime":"application\/octet-stream"} ]} 这是fodi的（在cloudflare那个界面可以调试到）： {"parent":"/","files":[ {"name":"d","size":14716769375,"time":"2020-07-23T14:14:52Z"}, {"name":"docs","size":5640494,"time":"2020-08-02T05:59:38Z"}, {"name":"readme.md","size":1311,"time":"2020-08-05T12:25:06Z","url":"https://blalaa...."} ]} 我们的思路就是让其输出一致，而且由于fodi客户端那个html是用的ajax请求ajax结果，?path并不是提交用的。而是作为form data被返回的。这是后来的问题，先处理输出一致。 因为正确的json是parent,files,name,size,time,url，所以在common.php function files_json($files)中： .... $tmp['list'] = [];改为 $tmp['files'] = []; ...... foreach ($files['children'] as $file) { ... $tmp1['name'] = $file['name']; //包括这句，以下三新加 $tmp1['size'] = $file['size']; $tmp1['time'] = $file['lastModifiedDateTime']; ... // $tmp1['type'] = 0; //这句注释 // $tmp1['type'] = 1; //这句注释 //$tmp1['id'] = $file['id']; //包括这句。接下来5句注释，中间3句被移到上面了 //$tmp1['name'] = $file['name']; //$tmp1['time'] = $file['lastModifiedDateTime']; //$tmp1['size'] = $file['size']; //$tmp1['mime'] = $file['file']['mimeType']; ..... array_push($tmp['list'], $tmp1);改为array_push($tmp['files'], $tmp1); ...... 加入parent,在main()合适的位置（对应于它在结果中输出parent字段在整个全部字段所在的位置，即$tmp['list'] = [];改为 $tmp['files'] = [];一句上面）加上 $a= str_replace($_SERVER['list_path'],"",array_pop(explode(":",$files['parentReference']['path']))); if (isset($a)) { $tmp['parent'] = $a; } if ($a =='') { $tmp['parent'] = '/'; } 不断测试url，随着path参数的改变，json终于有fodi相同的结果。这样，fodi终于接受到初步正确的数据了(仅初始)，，但是到现在为止,点击任何条目包括文件夹都不会出来正确结果，如上所说，我们只是让后端返回了我们认为正确的结果，我们的程序靠喂?path这个工作。到现在为止这仅是一种手动工作。fodi frontend并不与之联动，这是第一步，fodi前后端它是自动联动api path参数变化经的。比如，查看chrome f12,客户端还接受其它参数&encrypted=&plain=&passwd=undefined。（云开发会校验网页应用请求的来源域名，您需要将来源域名加入到WEB安全域名列表中。） 这是由于fodi客户端那个html是用的ajax请求ajax结果，?path并不是提交用的。而是作为form data被返回的。一个是用户发动的url path，一个是xhr发动的url request path，这二者不是一回事。fodi客户端服务端交互有它自己的逻辑。这里面还有复杂的ajax参数交互（查看chrome f12 ajax类请求产生的xhr对象）： 比如，消息体中的数据起作用,对于URI字段中的参数不起作用，被封装在xmlhttprequest的formdata中。服务端要还原处理这类formdata，，，这一切是因为服务器端请求参数区分Get与Post。get 方法用Request.QueryString["strName"]接收，而post 方法用Request.Form["strName"] 接收，blala..ajax还有其它细节。下一步：与fodi frontend对接。可能需要更多研究。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
利用fodi给onemanager前后端分离(1)：将fodi py后端安装在腾讯免费cloudbase
本文关键字：将fodi py后端安装在腾讯cloudbase 在前面《利用onemanager配合公有云做站和nas》中，我们提到onemanager是个可以装在腾讯云函数API网关或cloudbase上作为云函数的产品，onemanager php backend它本身也是调用onedrive的api，在前面《owncloud微博式记事本》《wp2oc fileshare》中我们也提到这种web api的修改定制。最近的《打造小程序版本公号和自托管的公号:miniblog》也是这种例子,后端cloudfuntion化，前端miniprogram则被部署到微信，，前后端分离和web api化调用是早已流行的趋势。 在《利用onemanager配合公有云做站和nas》中我们也提到要继续为onemanager找提高浏览体验用的缓存方案静态化方案，onemanager拉取文件列表延迟高体验不佳（这种延迟一部分就是它本身前后端不分离，一次返回结果混合了渲染html的客端逻辑，客户端也没有 ajax,另一部分是onemanager这类程序本身也是使用api的，返回结果来自OD本身是外部的，其只有有限的doctrine缓存技术，没有像混合云那样的多样化混合本地和远程云结果构建高效网站体验的能力），这次我们找到了fodi。其前后分离和客户端ajax技术，体验比单纯的onemanger要好得多，fodi分离的好处是，相当大部分逻辑都被放在了客户端。如浏览文件，服务器仅负责一次返回一些json数据，现在的浏览器本身一般也有本地缓存存储。，整个可以带来类似pwa,js based react native app的效果，这也是fodi名字中的fast的理念技术基础。 我们的目标是使od像fodi那样前后端分离，并研究尝试让它接上fodi前端的方法。----- 等等，直接用fodi前后端一套流不香吗？fodi有二个后端，一个backend_cf for cloudflare,一个py for 云函数，fodi py后端输出的是加密的json对我们接下来的研究不够直观化（除非chrome f12），而nodejs端直接输出直观的json结果，但nodejs runtime(<=10.15)又不支持addeventlistener()，它是cloudflare用的，所以我们打算用改造onemanager的结果来适配fodi前端。使之成为fodi的php backend。 注意：Fodi有部分预拉取列表功能，所以产生的云函数调用会比较多（所以推荐将fodi装到vps）,但是om的缺点是云函数调用流量方面也相对较多。 这里还是介绍将fodi后端部署到cloudbase的方法 上传和修改后端逻辑: 用cloudbase-cli提交backend-py： { "envId": "default-4gpm7vnrb911600e", "functionRoot": "functions", "functions": [{ "name": "fodi", //fodi就是backend-py "timeout": 6, "runtime": "Python3.6", "memorySize": 128, "installDependency": true, "handler": "index.main_handler" }] } 以下保证要使用https://xxxx.service.tcloudbase.com/fodi形式的调用路径(后台的接入路径定义)： def router(event): """对多个 api 路径分发 """ door = 'https://' + event['headers']['host'] print('door:'+door) func_path = '' #event['requestContext']['path'] //置空 print('func_path:'+func_path) api = event['path'].replace(func_path, '').strip('/') api_url = door + '/fodi' + event['path'] //加一个fodi串 queryString = event['queryStringParameters'] //这里改 body = None ...... 弄好后，访问上面的接入路径，仅/fodi，输出path error和后面一长串东西就代表服务器搭建正常， 获取refresh token 然后就是那个refreshtoken的获取，http://scfonedrive.github.io已经挂掉了，我们可以自建，先在某网站下建一个get.html: <html><meta charset=utf-8><body><h1>Error</h1><p>Please set the <code>refresh_token</code> in environments<br> <a href="" id="a1">Get a refresh_token</a> <br><code>allow javascript</code> <script> url=window.location.href; if (url.substr(-1)!="/") url+="/"; url="https://login.partner.microsoftonline.cn/common/oauth2/v2.0/authorize?scope=https%3A%2F%2Fmicrosoftgraph.chinacloudapi.cn%2FFiles.ReadWrite.All+offline_access&response_type=code&client_id=04c3ca0b-8d07-4773-85ad-98b037d25631&redirect_uri=https://scfonedrive.github.io&state="+encodeURIComponent(url); document.getElementById('a1').href=url; //window.open(url,"_blank"); </script> </p></body></html> 如果是国际版url换成: url="https://login.microsoftonline.com/common/oauth2/v2.0/authorize?scope=https%3A%2F%2Fgraph.microsoft.com%2FFiles.ReadWrite.All+offline_access&response_type=code&client_id=4da3e7f2-bf6d-467c-aaf0-578078f0bf7c&redirect_uri=https://scfonedrive.github.io&state="+encodeURIComponent(url); 再在根下建一个index.html <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>OneManager jump page</title> </head> <body> <a id="direct">No link here!</a><br> If not auto jump, click the link to jump.<br> 如果长时间未跳转，请点击上方链接继续安装。<br> <label id='test1'></label> <script> var q = new Array(); var query = window.location.search.substring(1); //document.getElementById('test1').innerHTML=query; var vars = query.split("&"); for (var i=0;i<vars.length;i++) { var pair = vars[i].split("="); q[pair[0]]=pair[1]; } var url = q['state']; var code = q['code']; if (!!url && !!code) { url = decodeURIComponent(url); if (url.substr(-1)!="/") url+="/"; var lasturl = url+"?authorization_code&code="+code; document.getElementById('direct').innerText = lasturl; document.getElementById('direct').href = lasturl; window.location = lasturl; } else { var str='Error! 有误！'; if (!url) str+='No url! url参数为空！'; if (!code) str+='No code from MS! 微软code为空！'; document.getElementById('test1').innerHTML=str+'<br>'+decodeURIComponent(query); alert(str); } </script> </body> </html> 把get中scfonedrive.github.io换成你的index.html所在的网站地址，（之后保证把py后端中用于认证的地址和那个clientid,clientsecret替换用你自己新建的一个，具体方法见我前面的一些文章） 调用后结果显示在url中（整个页面显示404是没有处理结果的php后端，除非你把https://github.com/qkqpttgf/OneDrive_SCF部署在index.html所在的网站），分辨复制即可。 安排好后端和refreshtoken后，调用接入路径/fodi/fodi/，输出看到其输出的加密的json结果，就代表refreshtoken也正常了。开始部署前端，可以另外一个网站，能托管html的就行。也可以在后端另起一函数，部署如下index.py: #!/usr/bin/env python # -*- coding:utf-8 -*- def main_handler(event, context): f = open("./front.html", encoding='utf-8') html = f.read() return { "isBase64Encoded": False, "statusCode": 200, "headers": {'Content-Type': 'text/html; charset=utf-8'}, "body": html } front.html当然是配置好的那个前端文件。 如果你fodi前端调用发生for each,length之类的提示错误，往往是refresh token没获取对。如果发生跨域错误（chrome f12可看到），则在后端面板中需要配置一条客户端网站的安全域名。 整个代码也较大，我们稍后将3rd依赖库精简掉，把那个加密逻辑去掉让输出常态化。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想
本文关键字：云时代没有软件，只有服务，虚拟app，虚拟OS，虚拟APP开发,metarootfs as service,container as service,virtual appliance，可devops编程os，Redox OS，融合app 我们知道，OS的选型，其实关乎着开发，因为它位于开发四栈中的平台栈部分，（系统开发语言对”系统平台“进行开发）平台与语言产生联系的方式首先是支持该OS开发中的toolchain language中的runtime（kernel space或user space中的libc），它以OS为宿主，将系统服务做成API件，将系统实现系统开发接上语言和开发。 与之产生比对的，就是该OS上的各种应用开发层次上的开发语言的后端，比如脚本语言，它可以是各种port到该OS平台上的虚拟机平台作为runtime接入到os，这种软件"虚拟机os"+“虚拟机平台上的语言，包装来自原OS toolchain的API或OS可开发服务即可，照样可以作平台上的系统开发。（比如c,cpp虽然可以桌面应用开发，但是它有开发效率不快学习曲线问题和内存泄漏问题而桌面开发不要求指令密集且不能跨平台，那就可以完全可以另起灶炉发明语言和一整套开发系统换成py这些）。甚至最后，虚拟机语言和脚本更多面向WEB，因为这种“API服务可以来自不同OS不同进程。的虚拟平台，不是OS也可以“。，云时代没有软件，只有服务。在《编程语言选型之技法融合，与领域融合的那些套路》和《一种matecloudos的设想及一种单机复杂度的云mateapp及云开发设想》中，我们都谈到，传统OS和语言是面向nativedev的提供语言系统和开发API的。，对于web和分布式来说，因为API和语言都不需要来自这类平台。更适用这些虚拟机平台和服务开发。----- 平台，语言后端，这二者的界限模糊了，语言可对虚拟，脱节平台进行开发。 后来又出现了容器，“语言后端即服务”。（baas,容器化，对语言来讲容器其实还是OS或虚拟机，它类似一种wsl，只不过它可视为分出来的子OS，这种子OS作用是为语言提供分离服务，而不是其它目的，比如pyenv,和serverless后端）。当然它们不是语言后端仅可视为后端包装器 ---- 只是这次，os平台，后端，容器，这三者的界限又变得模糊了。 以上这些都是平台与语言可完全脱节存在的例子。实际上，只要是脱离平台，该应用语言能对任何系统进行开发，甚至架空平台。 但是，它们本质上，它们都没有做到完全脱离。语言后端作为语言在这种具体平台上的实现支持语言在这种平台上存在，就是关系的纽带，不管何种形式存在（是对OS作后端还是OS上的虚拟机作后端），都有一个后端，都有一个OS存在：无论这种开发体和托管体，是single OS和APP之间，还是云服务时代，容器这种单元，只要它装配了语言后端，就可以解释为RUNTIME与OS的关系，这样这种后端与APP之间存在完备的运行支持关系才使之成为可能。即，它们是多平台而不是真正的跨平台，语言也并不是跨web/native开发，至少存在一种toolchain lang和一种appdev lang。（这里要明白一点：web不是平台是业务，lamp-l=amp才是runtime targetee,browser也是） 那么有没有完全脱离平台的语言呢，或者极大可能这样做的语言呢，这样做的好处又是什么呢？能给最终的开发（尤其分布式，WEB）带来帮助或颠覆性好处吗？ 语言与平台脱离：极小化语言，微语言 这需要从语言运行时本身进行。 这种语言和开发生态就是go和rust，这种极小运行时的语言。这就是我在《Golang，一门独立门户却又好好专注于解决过程式和纯粹app的语言》谈到的。go为每一个它生成的APP都内置了一个“go runtime as os”，而这种go runtime是不依赖任何平台甚至最初级的libc。 这种极小化生态，可以让语言更容易跨平台，甚至集成到浏览器（这是一种除了硬件嵌入开发的WEB嵌入式开发）。比如rust micro runtime之于wasm开发。而带GC的语言，往往不能用于嵌入式。 它带来的更大的好处之一，还可以使得virtual appliance成真。 virtual os与virtual appliance: 内置OS与language runtime的app 在云计算机和虚拟化领域，有virutal iaas，就会有virtual os，和virtual appliance。见《一个隔开hal与langsys，用户态专用OS的设想》，《一个设想基于colinux,the user mode osxaas for both realhw and langsys》。.上面谈到容器，作为language backend包装器存在，它也包装了OS。比如docker，实际上每个docker实例都共享着一套OS模板在最开头，其aufs文件系统的开头，也引用着一个OS rootfs。而现在，随着unikernel的出现。这种专门为OS kernel进行虚拟化（而不是在OS内部共享内核针对rootfs虚拟化的docker）的方案出现了，它使带OS的容器可以真正变得极小。它针对解决的问题是针对容器每一个模板过大的问题，就如同rust之于runtime一样,从源头解耦。 再来谈virtual app,最初的virtual appliance是本地虚拟机跨OS出现的一种APP管理机制，如vmlite的那种，pd的融合APP那种。而rust的微内核，使得用这种语言这种开发出来的APP，是无须调用或依赖任何OS导出的API或服务作为宿主的：不是可不可移殖，是根本无须移殖（OS与APP可脱离且最小化，这就给APP虚拟化提供了基础）。 如果说应用开发领域，OS可以虚拟化，模糊它作为app backend的意义，那么app为什么就不呢？关键是这二者一旦结合，将带来真正的virutal appliance和开发。 1）首先，Unikernel才能促成application virtual，微内核将容器做到os管理的级别跟openvz和docker方案不一样。微内核可以集成到APP级别。使得virtual appliance真的跨OS有存在意义。 2）其次，使得虚拟OS可以被集成在APP内，见《hyperkit:一个full codeable,full dev support的devops及cloud appmodel》，实现真正的virtual appliance，meta rootfs中集成虚拟机管理器。 3）1，2相加，针对那个最终的问题，可以带来更好编程的OS和分布式开发，使分布式真正集成到OS，在《一种matecloudos的设想及一种单机复杂度的云mateapp及云开发设想》，我们谈到现在分布式app都是跨OS的，但也存在一种原生分布式，即plan9,x11这种类似的“os绑定式分布式APP”， 该如何理解这种新appstack呢？传统的app是完成了gui,db,net之后在这上面，面向本地，堆应用，作为应用件，传统webapp是提出一系列关于db.gui,net的新规范（其中net部分固定为http）实现真正跨端，而新appstack是os限定的。跟传统os一样(受限于os透出的api/分布api)。新app是gui,db,net这三者，每一个都api化。且面向分布api化。作为开发件复合堆net关于分布网络。这里的思想类似于直接利用原生的os存储功能提供API和网盘服务。开发上，os即客服一体机器。语言库即os组件，见《一种matecloudos的设想及一种单机复杂度的云mateapp及云开发设想》第二节。 1，2，3可以使得nativedev适用于新的分布式开发，也使得传统web和web语言更容易拥有virtual appliance能力:webapp是初级的分布式和融合开发和融合栈的一种方式，因为它还没有涉及到virtual appliance和微内核容器化。任何应用编程，都是栈选型和归纳行为。归纳为有限几个栈。业务领域自有轮子。却没有真正的virtual appliance，因为web自身就是一种byond os的虚化平台，因此与web最搭的就是这种virtual appliance的appmodel。b端甚至可以不是浏览器直接是普通GUI。甚至结合rust microruntime和interpreter to js(这实现也是elmlang的特色)，可以用rust统一前后端开发。 rust的生态在慢慢涵盖我上面提到的那些rust coreboot，redox os微内核，User-space drivers 用户空间驱动，wasm,都在慢慢成真。目前这些只有molliza在做。感觉技术也是烧钱割韭菜。不过这套方案也确定是够slim省事。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
一种matecloudos的设想及一种单机复杂度的云mateapp及云开发设想
本文关键字：可编程的os/os kernel/os rootfs,os as service,os as service,mateos。cloudsubos，，客服同体，api/runtime共体，将os api化，headless os core for cloud api，融合云app matecloudos,matecloudapp:真正的分布式 在前面我们谈到《enginx,engitor》系列，还谈到《Plan9:一个从0开始考虑分布式，分布appmodel的os设计》，这些文章共同点都是对已有分布式app（一类跨OS/OS进程的APP）的思考和未来创新设想，可以拿来从各个方向类比：前者是传统os+lamp,lnmp方案，以OS上安装的分布式软件作为OS服务子组件（多见于服务器OS环境）透出它们的服务，在这上面打造出一个web appstack(比如apache之于page gui,mysql之于持久db...)，在这里，可利用的服务，和API存在于这些组件抽象给语言的后端（非OS固有部分），而后者plan9的本质不同之处则在于提出了一个devable os，将内核中的对象和os本身作为可编程对象，透出这些API服务，直接在已有OS组件上作分布式不提出LAMP之类的多余结构，在这上面打造分布式APP。 后者显然更原生，也更好用，（如上，传统的os只是api runtime/c dlls，api服务也是离线的另起一层，且并不面向分布式，并不是与开发一起被设计。是先把os用起来的原则建起来的，os与api分离。以前，为了达成跨语言跨OS的API，是靠给API打stub完成的。这种方式粗鄙无用已被淘汰不单是rpc技术改良就可以完成的）。而新时代分布式程序和分布式开发的固有特点是：分布式开发要求开发接口与程序本身共体不分离，也就是脚本语言和web开发中,“srcfile即程序组件”那套，------ 当然，现在的web分布式是从lamp上搭建的，现在的OS kernel也都基本不是plan9这类。但我们可以在现存传统的os结果下进行改造。比如，我们可以另外铺设API。将OS作为一种headless api被调用环境。类似传统方式铺lamp服务那样的方式进行：只不过这次向上提升到针对os的组件进行。也即，我们利用plan9思路和方式，从传统OS本身开始做而不下放到lamp，OS服务要作为基础被分布式服务化，发展基于OS分布化之下的分布APP。而且不必涉及到统一使用者的OS跨OS。，如果成功。本地开发和分布式分开完全可以统一。------ 引申开来，即：os/os kernel as serivce，api和api runtime天然一体。组件即demo即api。本地组件即远程服务(自动API化，无须再次面向不同语言作显式API化)。 新mateable分布式用于最小实践教育路径和降低实践门槛考虑 这样做具体有什么意义呢。 matecloudos和matecloudapp，由于OS都是自带文件系统，GUI，和持久的一类综合体，这些服务不必再搭建，作为客户机和作为服务器环境的作用可以统一彼此互为mate，这些理念对于APP开发的统一作用和难度降低作用不言而喻： 首先，（1）第一条，如上所述，本地开发和分布式开发将共享同样的技术基础，变成单机复杂度，我们现在的分布式分开几乎都是统一后端和webapp这二种理念：由于webapp是现在唯一的真正跨端的模型。。我们现在大部分移动端和一些native端应用都是通过分离前后端为统一后端+不同的客户端APP技术完成的，将所有分布式开发视为前后端分离，后端统一API化，都是web形式的调用，比如某个网站后端，或一个天然的cloud function，前端则利用统一的ajax,reactive,pwa技术构建。即所谓的MVC模型。这些都在《一种设想：在网盘里coding,debuging，运行linux rootfs作全面devops及一种基于分离服务为api的融合appstack新分布式开发设想》说过，如果os本身被api和服务化了，那么完全可以用native app逻辑。不必另造一个webapp出来。来达成分布式APP，简化后端。 （2）甚至，我们完全可以在类plan9的理念下统一，使分布式APP和本地native APP开发理念同源，再度降低APPDEV的难度，我们的开发一般都是某种app层次的dev，需要呈现为一个APP形式，比如web在是webapp，移动端是mobileapp，桌面就是nativeapp，软件和编程就二种逻辑和抽象：一个业务逻辑，一个关于APP本身的appstack逻辑。appdev的本质是三种stack（一般是gui,持久，网络）的形式在所处不同形式下的演化。比如文档数据库。就是视图模式下的“文档”，区别于存在于磁盘中的文档。appstack占了一个app逻辑的大部分，可以极大得到简化。 一个例子是类似p2p性质的gitcore客户端程序即是服务端程序，可以以同步的方式代替协议交互。也可以同步的方式来处理数据交互。比如，直接把原生GUI透出为分布式API服务，客户端也可以是远程桌面remote app这样的东西，如果客户APP也是服务端一样的OS，则GUI无须渲染（只需像那些远程桌面协议一样传送位移量）提出一种新的类web的remoteappmodel。天然分布式。 （3）还有，如果是plan9这种kernel，由于整个os内核都是构建于基于对象上。所以可以以编程的方式来调用和共享，以OS抽象和语言统一的方式（这个作用不得了，见《一种shell programming编程设想》，统一问题域和抽象域，甚至语言方案域）同步二个OS间的对象。这样在OS的构建过程中，就穿插预埋了对未来这种OS上的APP编程的设计，甚至统一了APPDEV和这种OS上的系统APP开发。 （4）更多，在线IDE就随处可放。调试也不再基于堆栈跟踪这些反工程层面。。。。。。 我们的设想是基于deepin做一个这样deepincloudos，再在这上面发展一些好用的matecloudapp(集成云开发IDE和云LAMP，首要的就是在线IDE和mineportal apps:如file explorer内置同步，如果能在jupyter上写程序，那么这是一个天然debug backend app，已有这样的产品，不过这是工具层面的，我们就是要将其做到与OS级天然集成。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
打造小程序版本公号和自托管的公号(3):为miniblog接入markdown和增强的一物一码
本文关键字：微信一物一码，一文一码，小程序码转为普通二维码 在《打造小程序版本公号和自托管的公号2》中我们讲到了miniblog的初级搭建和定制，这里继续： 加入markdown编辑 前面说到miniblog的8个函数中，前6个函数可以整合，剩下synservice,synctoken不必整合。可以丢弃或保留（保留使用它的意义不甚大，这种同步结果和过程比较曲折，体验不好，要使用它，记得syncservice/index.js/function syncWechatPosts(isUpdate) 中应该 let data = { currentOffset: 0, maxSyncCount: 由10改为1000 } ，同时提醒用户把该函数超时时间设置大一点。 否则很难有正确结果。我120数据用了8秒。不要太频繁调用这个函数，免费额度会减少。也不要搞按时自动触发。这底下是因为那个函数内，调用公号素材库未发布文章一次只能取到20条，循环获取就是maxsynccount指定的最大结果）。丢弃的情况下,我们则需要依赖内部的发布文章机制，由于手机实在不好发文作富文本修饰或输入（除非chromebook,apple arm macbook真的广泛用起来了，人们用它办公和文字生产了），粘贴复制还是可以的，所以最好是markdown的那套。目前miniblog的那个编辑器可以发markdown前端也能通过toxml渲染,但是测试了一下，不能修改和更新文章。 首先，加入miniblog的编辑文章功能。mini-blog-d02344fe6c6b347057983edd1ef6b7450f88fbcc这个rev删掉了发文功能（审核问题删了。），去它的上个版本把文件下载回来修改相关wxml,js调用加进去。然后是把富文本编辑器定制成markdown： miniprogram/pages/admin/article/article.js中: savePost: async function (e) 函数内： contentType: "markdown", //这里由html改为markdown content: res.text, //这里由res.html改为text getContent: function () 函数内： resolve(res.text) miniprogram/pages/detail/detail.js中：let content = app.towxml(postDetail.result.content, 'markdown'); 小程序首页和文章详情也都是调用toxml的地方，实际上，小程序首页如果文章比较多下拉后返回上面很费事，你可以顺便做个添加一个回到顶端，wx.pageScrollTo({scrollTop: 0,duration: 300})。由于源码中toxml是放到src根下的，你还可以把toxml放进miniprogram/component文件夹内，这里是放小程序组件的地方（由于本地的js版本不一，编译miniprogram最好是本地进行，提取dist下生成的用。这也是前面文章提倡就地npm install编译的道理），移动后修改相关路径(component json和miniprogram/app.js中)。接下来会谈到把海报生成poster组件也放进来。 加入增强的一物一码 小程序实际上它也是web原理的page app，有各种路径和调用参数，(IDE左下角可以看到)，而二维码是一种编码解码机制，的背后要么是某段文字要么是某个网址，工作原理是经过图像扫描，编码解码得出码后的结果。为app所用。微信支持三种为小程序生成二维码的API，可以为小程序本身和小程序各种页面和带参数的页面调用生成二维码。即所谓支持一物一码，这里是文章，所以是一文一码。 miniblog中有一个海报生成，里面就有二维码生成，它被放在了前端文章详情页，miniblog用的是api中的getunlimit()，可以为/page/detail/detail?id=blogid形式的带参页面生成对应小程序码，如果有100篇文章可以生成100个二维码。这种api生成的二维码是小程序样式的。较普通方块二维码有些缺陷（比如它难扫，而且这种小程序码中间一个大大的logo很占位置），最重要的问题是：它背后没有一个https打头的url：微信后台对其一物一码的绑定url，虽然它是页面但其实它是小程序页面不是https，仅限该miniblog小程序内绑定，我们需要把mini/index.js/getunlimit()换成createqrcode（较getunlimit和get，这个能得到普通二维码。get和createqrcode各有5W多的限额共10够用）: async function addPostQrCode(event) { //let scene = 'timestamp=' + event.timestamp; let result = await cloud.openapi.wxacode.createQRCode({ //scene: event.postId, path: 'pages/detail/detail?id=' + event.postId, width: 280 //结果得到的从280到1280，我这里只要最小的 }) ..... } 这样就得到了普通二维码图片（中间LOGO，底下有一个提示语扫码使用小程序的提示）和带https的微信扫码绑定机制，我们把它叫作decodeqrcodeurl。得到这个，我们可以为其重新编码生成二维码，这样再处理之后的二维码有什么用呢，比如，用we-app-qrcode之类的组件再处理，不仅可以将提示语和LOGO去掉，而且可以用草料等工具定制美化。还可以可以压缩其体积，生成base64，供同一份内容的多次外发的文章脚部链接小程序二维码使用。真正让一物一码做到极致。 在mini/index.js中，我们加入重新解码的逻辑： 头部加入： const decodeImage = require('jimp').read const qrcodeReader = require('qrcode-reader') async function addPostQrCode(event)前加入： //解码二维码buffer function qrDecode(data,callback){ decodeImage(data,function(err,image){ if(err){ callback(false); return; } let decodeQR = new qrcodeReader(); decodeQR.callback = function(errorWhenDecodeQR, result) { if (errorWhenDecodeQR) { callback(false); return; } if (!result){ callback(false); return; }else{ callback(result.result) } }; decodeQR.decode(image.bitmap); }); } async function addPostQrCode(event)中加入： async function addPostQrCode(event) { .... if (result.errCode === 0) { qrDecode(result.buffer,function(urlcontent){ console.log("decode:" + urlcontent); }); ..... } 在mini下npm install -save jimp和qrcode-reader可以在package.json中加入： "dependencies": { ..... "jimp": "^0.16.0", "qrcode-reader": "^1.0.4", ..... } miniprogram方面，文章详情页的分享小程序页面本来就存在，拉取（海报中的）二维码又涉及到服务端调用返回二维码费资源，干脆不交给用户，将它做成admin page内供管理员编辑文章处用更合适。也可以达到同样由用户来生成二维码的效果。还更可控，适用。比如，可以砍掉生成整个海报其它部分仅保留二维码生成部分，然后转移相关wxml,js函数调用，component定义（包括js中的初始data定义）到admin/article/articlelist页（不要放在article/article，批量操作不现实），按钮跟那些“展示”，“专题”，“标签”小红方块放一起，当还要定制主逻辑函数，具体如下： //utils/api.js中， function getNewPostsList(page, filter, orderBy) {}和function getPostsList(page, filter, isShow, orderBy, label) {}中，这二函数的_fields都加起：qrCode: true来，以便在articlelist.wxml中能： <view class='cu-tag bg-red bg-{{item.qrCode == undefined?"red":"green"}} light' data-postqrcode="{{item.qrCode}}" data-postid="{{item._id}}" catchtap='onCreatePoster'> {{item.qrCode == undefined?"未生码":"已生码"}} </view> //然后是主函数： onCreatePoster: async function (e) { let that = this; let postid = e.currentTarget.dataset.postid console.info(postid) let postqrcode = e.currentTarget.dataset.postqrcode console.info(postqrcode) let qrCode = await api.getReportQrCodeUrl(postqrcode); let qrCodeUrl = qrCode.fileList[0].tempFileURL console.info(qrCodeUrl) that.data.posterImageUrl = qrCodeUrl if (postqrcode == undefined || that.data.posterImageUrl == "") { let addReult = await api.addPostQrCode(postid) qrCodeUrl = addReult.result[0].tempFileURL } else { that.setData({ posterImageUrl: qrCodeUrl, isShowPosterModal: true //model是模态对话框意思 }) return; } let posterConfig = { width: 600, height: 600, backgroundColor: '#fff', debug: false } var blocks = [] var texts = []; texts = []; var images = [ { width: 560, height: 560, x: 20, y: 20, url: qrCodeUrl,//二维码的图 } ]; posterConfig.blocks = blocks;//海报内图片的外框 posterConfig.texts = texts; //海报的文字 posterConfig.images = images; that.setData({ posterConfig: posterConfig }, () => { Poster.create(true); //生成海报图片 }); await that.onPullDownRefresh() }, //你会发现列表是按createtime排的，utils/api.js中要改成timestamp, if (orderBy == undefined || orderBy == "") { orderBy = "timestamp" } //然后utils/api.js中function getNewPostsList的检索条件和index.js中的检签逻辑(记得把总体文字缩短否则idx6之后显不出来，我是把已xxx全删了仅保留未xxx)也加起来。 if (filter.qrcoded == 1) { where.qrCode = _.nin(["", 0, undefined]) } if (filter.qrcoded == 2) { where.qrCode = _.in(["", 0, undefined]) } //如果你还想把生成的一物一码自动欠入各文章详情页内。，代替原来的onpostcreater()位置，那么可以 showQrcode2: async function (e) { let that = this; let qrCode = await api.getReportQrCodeUrl(that.data.post.qrCode); let qrCodeUrl = qrCode.fileList[0].tempFileURL wx.previewImage({ urls: [qrCodeUrl], current: "一文一码" }) }, 整个过程依然都是在IDE模拟器中不断的修改，调试，再调试（提一下，我用的IDE是deepin20商店中https://github.com/cytle/wechat_web_devtools编译的，这个IDE腾讯官方没有列出为支持项）。要注意服务端的在函数后台看日志，IDE只能看出客户端的输出，由于上面是加入到服务端函数后端的，因此调试结果console.log("decode:" + urlcontent);在IDE端是看不到的（除非你打开IDE中的函数调用日志）。突然发现小程序用于实践很微粒化。一天一个微程序，像jupyter一样每天练习，持之以恒，可以积累下大量的语言和项目开发经验。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
打造小程序版本公号和自托管的公号(2)：利用mini-blog将你的blog做到微信
本文关键字：合并多个cloudfuncions为一个 在《打造小程序版本公号和自托管的公号(1)》中，我们谈到了建立blog小程序的一些理论基础和必要条件，现在，我们选择一个这类小程序的源码，来实践一下： 我们选择的是https://github.com/CavinCao/mini-blog/commit/7921a126122f4a980e1270475aeb22bb2d50c3d0，积分功能v2版本后面的一个修复版，为什么选mini blog，因为它小。该有的都有，不该有的也没有。很容易看清这类实践的基本套路和这类程序的技术手法，下载源码后打开微信开发IDE，扫码IDE左上角小程序（开发社区号）绑定微信，，用IDE导入正确路径下源码，appid填你注册过的小程序appid，因为miniblog使用的腾讯云cloudbase托管的云函数后端（当然miniblog还用了cb的数据库），在点击云开发按钮新建第一个数据库或云函数之前，它会自动帮你注册或绑定已有的一个腾讯云帐号，为了达到在已有帐号里操作的效果，请保证预先处理你绑定IDE用的微信，它背后的某个腾讯云号已有绑定该小程序作为登录方式之一，这样新建云函或数据库会自动在你已有的腾讯云的cloudbase下进行，如果你使用了自动生成的腾讯云号，那么会得到一个新帐号已绑有小程序登录但未绑定微信，需要二次登录（先微信后小程序）才能进入帐号，解决方法是在那个新帐号里绑定一次微信。 IDE打开，我们发现源码有cloudfunctions云函和miniprogram小程序，点云开发，新建一个clodubase环境包月免费自动续费，登录web版会发现用IDE建的是只读的而且与网页端申请的那个免费可以共存，。接下来就是miniblog的安装：有12个库（access_token,mini_posts,mini_comments,mini_posts_related,mini_config,mini_logs,mini_formids,mini_member,mini_sign_detail,mini_point_detail,mini_subcribute,mini_share_detail），和8个函数，安装12库比较简单，记得把权限全设为所有只读仅管理员和创造者修改，如果稍后你发现编出的小程序有各种BUG，那么可能是12库少安装了某个或某些，或漏了权限没改过来。然后在IDE里定位到正确的cb部署环境，在IDE文件浏览器下点击各个函数对应的文件夹，右击部署（包括安装node modules方式），一一给函数的版本管理->配置处添加Env:cb名的环境变量项，其中syncservice还需要提供内容同步的公号的AppId和AppSecret，adminservice还需要author:你的管理者微信的openid串（可在稍后调出小程序界面后切到/index/index/从ide的console中直接输出的信息复制得到），miniprogram只需改下utils/config.js里的env id到正确的cb名，还需要在IDE文件管理器中右击index/posts/detail打到命令行安装一个客端模块：npm install wxa-plugin-canvas --production (设置，项目设置处勾上使用npm模块)，至于源码用的各种templateid，由于是公共ID，所以不用修改。小程序前后端基本能一起工作起来了，执行一次synservices拉取一些测试文章（根据错误添加IP白名单）。 下面，我们来深度定制它： 将8个云函数合并 由于部署8个云函数带来了管理上的困难，也显得零散，所以我们把它合并成一个叫mini的云函数中去，思路是先在cloudfunctions下新建mini，把各xxxservices中的config.json，package.json合并去除重复部分放到这，package-lock.json可删掉，如以下修改： config.json(json不允许注释用时需要去掉//后的内容,下同) { "triggers": [ { "name": "myTrigger", "type": "timer", "config": "0 30 8 * * * *" } ], "permissions": { "openapi": [ "wxacode.getUnlimited", "templateMessage.send", "templateMessage.addTemplate", "templateMessage.deleteTemplate", "templateMessage.getTemplateList", "templateMessage.getTemplateLibraryById", "templateMessage.getTemplateLibraryList", "subscribeMessage.send", "subscribeMessage.getTemplateList", "security.msgSecCheck" //注意这个 ] } } package.json： { "name": "mini", "version": "1.0.0", "runtime": "Nodejs8.9", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC", "dependencies": { "date-utils": "^1.2.21", "request-promise": "^4.2.4", "towxml": "^2.1.4", "hydrogen-js-sdk": "^2.2.0", "request": "^2.88.0", "wx-server-sdk": "^1.8.2" //注意这里，提到了最高版 } } 然后是重点整合部分，把各个index.js整成/mini下总的index.js（login/index.js已被如下融合，除外）: //////以下从各个index.js头部整合到的全局变量 const cloud = require('wx-server-sdk') cloud.init({ env: process.env.Env }) const rp = require('request-promise'); const dateUtils = require('date-utils') const db = cloud.database() const _ = db.command const RELEASE_LOG_KEY = 'releaseLogKey' const APPLY_TEMPLATE_ID = 'DI_AuJDmFXnNuME1vpX_hY2yw1pR6kFXPZ7ZAQ0uLOY' //收到评论通知 const template = 'cwYd6eGpQ8y7xcVsYWuTSC-FAsAyv5KOAVGvjJIdI9Q' const Towxml = require('towxml'); const towxml = new Towxml(); const COMMENT_TEMPLATE_ID = 'BxVtrR681icGxgVJOfJ8xdze6TsZiXdSmmUUXnd_9Zg' //////以下整合的main,用了自建的route分发，实际上就是折分二个return：event,openid exports.main = (event, context) => { console.log(event) console.log(context) //注释掉 //return { // event, // openid: wxContext.OPENID, // appid: wxContext.APPID, // unionid: wxContext.UNIONID, //} //这句重要 return router(event) } async function router(event) { //从main中移到这里 const wxContext = cloud.getWXContext() //不需要了 //if (event.action !== 'checkAuthor' && event.action !== 'getLabelList' && event.action !== 'getClassifyList' && event.action !== 'getAdvertConfig') { // let result = await checkAuthor(event) // if (!result) { // return false; // } //} switch (event.action) { //postsservices case 'getPostsDetail': { return getPostsDetail(event) } case 'addPostComment': { return addPostComment(event) } case 'addPostChildComment': { return addPostChildComment(event) } case 'addPostCollection': { return addPostCollection(event) } case 'deletePostCollectionOrZan': { return deletePostCollectionOrZan(event) } case 'addPostZan': { return addPostZan(event) } case 'addPostQrCode': { return addPostQrCode(event) } case 'checkPostComment': { return checkPostComment(event) } //按葫芦造样，把memberservices,messageservices,adminservices,scheduleservices,syncservices,syncTokenservices其它case部分也弄到这 //注意这句 case default : return {openid: wxContext.OPENID} } } ..... //再接下来就是从各个原xxxservice/index.js中移过来不包括开头变量和main()的代码的部分,直接复制即可。 然后就可以删掉所有xxxservices文件夹了，客户端修求主要集中在utils/api.js和app.js中。将它们改为全部callfunction("mini")，完工！！ 将主题集成到首页 由于主题被做成了一个与文章首页和我的（后台）并列的项。不爽。将其归到首页“最新，热门，标签”后的“主题”文章部分。 index.wxml，从topics.wxml中提取到这里，介于搜索栏和文章列表之间 <!-- 专题列表 --> <view class="cu-list menu card-menu margin-top" wx:for="{{classifyList}}" wx:key="idx" wx:for-index="idx" wx:for-item="item" id="{{item._id}}" data-tname="{{item.value.classifyName}}" bindtap='openTopicPosts'> <view class="cu-item"> <view class="content padding-tb-sm"> <view> <text class="cuIcon-title text-orange "></text> {{item.value.classifyName}} </view> <view class="text-gray text-sm"> {{item.value.classifyDesc}} </view> </view> </view> </view> 由于展示是依靠js的，所以index.js: data: { classifyList: [], posts: [], ..... navItems: [{ name: '最新', index: 1 }, { name: '热门', index: 2 }, { name: '标签', index: 3 }, { name: '专题', index: 4 }], ..... } ..... // 如下设置内容，避免UI块重叠 tabSelect: async function (e) { ...... case 1，2，3: { that.setData({ ..... showHot: false, classifyList: [], showLabels: false, //case3时为true posts: [], ...... }) ..... } case 4: { that.setData({ ...... showHot: false, showLabels: false, classifyList: [], posts: [], ..... }) let task = that.getClassifyList() await task break } } 把函数getClassifyList: async function ()从/topics/topics.js中移到这，可把topiclist文件夹也移过来到index/下，修改相关路径,之后可以删掉topics文件夹了， 你还可以修改一些硬编码的东西。 app.json: "navigationBarTitleText": syncservice/index.js: totalComments: 0,//总的点评数 totalVisits: 100,//总的访问数 totalZans: 50,//总的点赞数 pages/mine/mine.js，申请vip的提示语等 一些未来改进建议： 后台管理，留言可以加一个是否开启审核，“程序有一点点小异常，操作失败啦',这类消息提示可以更精确。因为一般都是数据库权限或templateid问题。 templateid位置： adminservice/index.js : APPLY_TEMPLATE_ID postservices/index.js评论：COMMENT_TEMPLATE_ID utils/config.js：subcributeTemplateId messageservice/index.js, template 评论被回复模板ID scheduleservice/index.js签到提醒：SIGN_TEMPLATE_ID mine/sign/sign.js:tempalteId pages/mine/mine.js申请vip: tempalteId 整个过程都是在IDE模拟器中不断的修改，调试，再调试。之后就是提交体验了，提交体验版本然后微信浏览基本接近以发布后效果而IDE中的模拟器较之有一些效果体现不出来，还有，审核的时候有可能会说你动态网站不能通过很奇葩，那么以cloudbase为后端意义何在？ 下文我们将用fodi分开前后端的方式来划分onemanager将它做成miniblog小程序的内容源或者给miniblog直接弄一个PC网站前端和pc网站后端写作模块。其实小程序和onemanger非常像。因为后者也是云函数为后端，只不过一个定位网站前端，一个定位小程序前端。后端都是api服务。mini blog for wechat是直接利用cloudbase sdk调用云函，天然鉴权请求，而onemanager的前端是利用普通网站提交，基于url route提交请求。fodi前后端利用更高级的ajax。这三者都有相似之处,其实cloudbase也可用于google flatter和mobile apps。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
一键pebuilder，实现云主机在线装dsm61715284
虽然群晖上云没有什么很大意义，因为云主机附属的带宽和存储成本现在还没有做到类似onedrive不限速，几百元1T一年的程度。类似cos,oss这种有api的”类od网盘“成本也偏高实用性也不大，群晖这种OS也没有完全做到以网络硬盘为后端存储，它倒是支持一种分布式硬盘的iSCSI只不过这种分布式是大架构用的海量存储方案。在应用方面，群晖大量采用开源技术，也有一些自研的应用比如xxstation组合，但是cloudstation的sync算法经常会导致冲突，但是anyway，群晖的webstation是个很好的php虚拟主机管理面板，也可以作为网盘间内容转存器，因为它有cloudsync(不过百度盘最近又限制了cloudsync的配额，其一惯作风~)。所以还是来折腾一下： 技术背景 1,aiminick在nasyun上发布http://www.nasyun.com/thread-31988-1-1.html的《DS3615xs直升DSM6.1.4U2【KVM平台虚拟机】加强版引导镜像》: 作者结合利用了jun大引导和老骥伏枥二合一引导（这二个是平等作用的东西，前者有外挂驱动完成了黑群的主要部分，后者主要是多合一，可以用jun大引导中的三个文件extra.lzma、 rd.gz 、 zImage替换老骥伏枥/boot/grub/DS3615xs 下同名文件，主要是extra.lzma，这个文件以沙盒补丁的形式对黑群文件系统进行patching），重新编译了syno内核和virtio modules替换了相关文件,在本地kvm上完成测试了最新版黑群614系列pat的安装，(除此之外他还更新了一篇3615xs 6.1.7的kvm安装，除更新了版本支持值得一提的是这个版本去掉了老骥伏枥引导中的grub1,tinycorelinuxpe等，仅保留了grub2部分)。 这证明kvm黑群（类似《在阿里云上单盘安装群晖skynas》和《dsm as deepin mate》系列针对的skynas。但纯粹的kvm黑群方案相对更原生。）也是可以做出来的（虽然接下来我们会谈到，使用aiminick的包在kvm上折腾还是有人碰到很多坑），但是aiminick并没有解决sda->vda的问题，使用的virtio ide方案。云主机所属的kvm使用virtio blk或scsi。这个问题也在第一篇黑群文章中就提到了。 2,作者tiandishi在nasyun上发布http://www.nasyun.com/thread-70722-1-1.html的《群晖上云服务器,完成度90%！！》，搞定了上述问题，并进一步修复了阵列问题，得出了最新版单盘安装黑群的方法并介绍在了另外一个贴子里。 tiandishi没有直接采用aiminick的包在kvm上折腾，他仅采用aiminick的选型和编译方案（615机型和linux-3.10.x.txz内核），倾向使用原始的老骥伏枥DS3615xs黑群晖 6.1-15152版中的文件制作启动，却使用了jun大ds3615xs 6.1.7引导来做，仅最小替换virtioblk来测试，他重新编译了能识别vda为sda的dsm6.1内核和驱动模块，他修改了 linux-3.10.x.txz 中源码的drivers/block/virtio_blk.c,修改 virtblk_name_format("vd", index, vblk->disk->disk_name, DISK_NAME_LEN); 这一行的vd为sd。先从virtio ide+虚拟机下（proxmox kvm下）开始，按正常IDE盘格式和折腾aiminick的3617的包在kvm上安装617pat并进该硬盘的系统，不断打包进新引导包替换测试，如果失败则回退到原处再次测试，最终发现新的引导可以产生与aiminick测试类似的结果：安装 3615xs, 6.17,15284 版本的系统至完结.虽然至少此时正确能识别硬盘为sda，但这也是新问题的开始，因为他导致了不能重启后正常使用（值得一提的是在tiandishi的包中，他保留了其中tinycorelinuxpe，因为它日后可以用来修改grub中的mac）： 1）现象：启动时发现无法识别群晖的/dev/md0 /dev/md1 软raid系统,导致认定系统未安装,重新进入安装界面.作者分析2）原因：发现这是因为单盘系统盘是一个软raid1的软阵列，黑裙引导的时候需要识别这个阵列并加载阵列的系统。但当硬盘类型为virtio_blk的时候，内核启动检测阵列使用的 mdadm --auto-detect 这个命令不会映射virtio_blk到阵列专用的设备符/dev/md0,进一步导致内核执行/usr/syno/bin/synocheckpartition 的时候返回结果为Partition Version=0，报错Partition layout is not DiskStation style.;需要替换为 mdadm --assemble --scan ,这样可以正常识别阵列分区, 使得/usr/syno/bin/synocheckpartition 返回正常结果 Partition Version=8. 临时解决。3）方法：去掉virtio盘的虚拟化blk格式，按正常IDE盘格式和折腾aiminick的3617的包在kvm上安装617pat并进该硬盘的系统，仅为得到一次磁盘信息，正常安装下头二个区一个2G一个2.4区为软raid区，这相当于在系统内mdadm --detail --scan > mdadm.conf，获得的关于镜像盘的如下md/blkid相关信息， ARRAY /dev/md0 metadata=0.90 UUID=57d437b5:798159fc:3017a5a8:c86610be 你需要手动修改uuid为你的盘的uuid ARRAY /dev/md1 metadata=0.90 UUID=7580a324:5f709df7:dcd287d5:29e3aff2 ARRAY /dev/md2 metadata=1.2 name=yunnas:2 UUID=b96e00a8:dab9a2b6:c99e9210:f50c9dbf (这个盘是数据盘请略过) 这个mdadm.conf将被放进extra.lzma/juno/etc/中作为解决新系统不能重启运行的补丁,手动喂给booter调用：修改linuxrc.syno的补丁文件jun.patch ，在内核挂载阵列设备 /dev/md0 前执行 mdadm --assemble --scan，该命令优先读取上面的配置文件，识别出硬盘阵列，然后后面的挂载系统能顺利执行。 mdadm -S /dev/md0 && mdadm --assemble --scan echo "Mounting ${RootDevice} ${Mnt}" 放这句上面 打包extra.lzma ，扔进引导，重新启用virtio盘的虚拟化blk格式。测试成功进入系统！还有二个后期小问题：1，启动后其它数据盘部分无法识别，需要添加一个临时数据盘组raid（这个可结合我《Dsm as deepin mate(2)：在阿里云上真正实现单盘安装运行skynas》处理tmp/space.xml的方法尝试解决），2，启动后添加的网卡拿不到IP，需要修改grub引导中mac的地址。但都非关键问题了 下面直接制作镜像，用tiandishi的路子,找对版本,先搞定识别sda安装完系统，再搞定阵列修复进入系统： 制作镜像 准备工作：我们直接使用jun大ds3615xs 6.1.7引导(注意这混乱的版本命名，3615是硬件平台，617是内核，15284等是pat)和原始的老骥伏枥DS3615xs黑群晖 6.1-15152版中的文件（用jun大617替换里面的原615引导的相关文件，/boot/grub/ds6135xs就不改成ds6137xs了以避免需另改grub.cfg）,和tiandishi弄好的http://down.nasyun.com/forum/202005/17/064451tfwjwlvwawylwwgj.zip?_upd=kvmdrive.zip,q外面的那个virt_blk.ko仅仅适用于3.10.102内核编译的系统。前者是引导，后者是补丁， 制造下面的617kvmboot： qemu-img create -f raw 617kvmboot 32M fdisk 615kvmboot自动dos mbr，n自动一区，a自动激活 losetup -fP --show 617kvmboot mkfs.vfat /dev/loop0p1 mkdir bootmnt mount /dev/loop0p1 bootmnt/ grub-install --boot-directory=bootmnt/boot /dev/loop0 ...(复制boot所需文件进来，不要把各种tcpe,legacy grub复进来，，先kvmdrive.zip中重命名extra.lzma中的etc/madam.conf(deepin下可以直接编辑名字自动gui打包)，以防其它非意料因素出现，用extra.lzma直接替换617kvmboot中的extra.lzma即可，另外修改grub.cfg中virtio mac地址一定要525400开头否则一会识别不到。有调试需求，则可以在grub.cfg中将虚拟串口设置为开机不自动启用。).. umount bootmnt losetup -d /dev/loop0 替换后的镜像也都是mbr虚拟机/云主机适用的，依然是我们前面的在pd中装deepin，开kvm，再启动qemu制造主镜像，二步走，第一步用qemu-system-x86_64 制造镜像，第二步用qemu-system-x86_64 测试启动镜像，如果不分二步，直接上来virtioblk，会提示格式化失败 第一步: qemu-img create -f raw dsm61715284 20G qemu-system-x86_64 -enable-kvm \ -machine pc-i440fx-2.8 \ -cpu Penryn,kvm=off,vendor=GenuineIntel \ -m 2120 \ -device cirrus-vga,bus=pci.0,addr=0x2 \ -usb -device usb-kbd -device usb-mouse \ -hdc ./617kvmboot \ -hda ./dsm61715284 \ -device virtio-net-pci,bus=pci.0,addr=0x3,mac='52:54:00:c9:18:27',netdev=MacNET \ -netdev bridge,id=MacNET,br=virbr0,"helper=/usr/lib/qemu/qemu-bridge-helper" \ -boot order=dc,menu=on 这一步会出现网上很多人拿DS3617xs_DSM6.1_Broadwell.img在kvm下折腾都出过一些问题，新的booter也会有，如下： 引导进入dsm，安装时局域网扫不出ip，除了可能开头就提到的你grub.cfg中virtio mac地址没有改成525400开头否则识别不到,如果dsm已识别网卡，只是扫不出而已。也可以这么做：从宿主机看guest分到的ip(arp -a)，或者找个脚本扫virbr0所在的网段了（192.168.122.2到254）。我这里得出是192.168.112.32或78，以后几乎固定都是这个不用再扫，如果还是得不出ip，重启宿主deepin再来(我发现aiminick的网卡识别比较好和效果稳定)，deepin中用chrome打开，在webassit上显示对应的ip也不是上面指定的mac，被改变了，如果连不上重启虚拟机重来，连上了webassit，下载pat,准备手动安装的https://cndl.synology.cn/download/DSM/release/6.1.7/15284/DSM_DS3617xs_15284.pat。安装的时候提示格式化 1 2 硬盘，勾选安装就可以了，引导盘不会被格式化，如果pat版本没匹配，会出现各种安装到57%左右文件毁损， 如果没有问题，系统安装完成，进去命令行mdadm --detail --scan > mdadm.conf,检查输出(本来设计对镜像作blkid和tune2fs -U写入uuid，但那个2.4g的是个swap fs，无法这样完成，故还是修改mdadm.conf)，生成的文件重新整合到xtra.lzma，则可以继续第二步，启动测试。 第二步: qemu-system-x86_64 -enable-kvm \ -machine pc-i440fx-2.8 \ -cpu Penryn,kvm=off,vendor=GenuineIntel \ -m 2120 \ -device cirrus-vga,bus=pci.0,addr=0x2 \ -usb -device usb-kbd -device usb-mouse \ -hdc ./617kvmboot \ -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=MacHDD \ -drive id=MacHDD,if=none,cache=writeback,format=raw,file=./dsm61715284 \ -device virtio-net-pci,bus=pci.0,addr=0x3,mac='52:54:00:c9:18:27',netdev=MacNET \ -netdev bridge,id=MacNET,br=virbr0,"helper=/usr/lib/qemu/qemu-bridge-helper" \ -boot order=dc,menu=on 最后，第三个分区20G-4.5G开起来。且开第四个分区用于在主镜像中制造硬盘引导为日后脱离617kvmboot也能引导，即并losetup挂载将617kvmboot中的内容以及引导再次离线写入到生成的镜像的第四分区，tar cvpzf它，并将最终镜像上传到onedrive互联。 完工！ 利用pebuilder在云主机上安装 由于pebuilder.sh足够智能就不用保留tcpe对于mac的替换，况且这需要在具体目标系统中完成。比如放在pebuilder完成dd后要重启的位置，你可以直接将处理mac的逻辑放这里：(grub.cfg中可以写function，为什么在那里不做？一定要在进入系统后？)，以至于这里也可能可以跟处理mac一样放处理tune2fs的逻辑： d-i partman/early_command string $PIPECMDSTR; \ sed -i 's/mac1=52540066761B/mac1=yourmacaddr/g' \$(list-devices disk |head -n1)4/boot/grub/grub.cfg \ sbin/reboot 要看pebuilder.sh gif演示的。去我的github，下文，用开源包替换cloudstation和用videosstation云转码 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
一个设想，在统一bios/uefi firmware，及内存中的firmware中为pebuilder.sh建立不死booter
本文关键字：firmware in RAM' replacements for UEFI firmware，虚拟efi,编译类colinux的linuxboot 在《云主机装黑果实践》上我们反复提到一种在bios上也能运行的uefi，这就是变色龙和四叶草。它在内存中模拟一份虚拟的firmware和efi机器环境，以对接需要efi环境运行的os（如果是bios机，可以模拟一份全新efi，如果是uefi机，可以替换或修改相关uefi项），------这样无论是legacy系统还是新机器是实机还是云环境，都可以制造一层一致的中间层机器固件环境和功能来定义os运行所需环境 . 在一致的中间层firmware中我们能干啥 在这种”中间层固件，软件化的固件“中，除了硬件加载部分，我们可以写入各种payload（即uefi的app,如一份efi shell，如一份linuxboot中的vmlinux和rootfs，实际上，linuxboot即是这种技术，它保留原vendor firmware的硬件加载部分，把uefi app部分替换成linux+linux rootfs，比如headfirmware：一份集有虚拟机管理器的linux或uboot：一份集有userland golang busybox替代的linux）。，------ 然后，在实机上，这样的一份firmware可以被直接刷入bios rom或spi rom，在云主机或虚拟机中，它们可以被刷入分区代替firmware硬件rom区(相当于强化了的booter,with firmware included)，为bios机重新定义firmware，---- 实际上，群晖中，由initrd和updater.pat组成的二层rootfs，它的第一层initrd即是一个meta rootfs，适合放在这样的firmware区中。所以黑群的引导，从以上的观点中，可以理解为整个引导所在区组成的firmware(也可以理解为linuxpe)，而实际上，这一部分，在白群中，的确是被刷入主板的spi中的。 为pebuilder.sh建立不死booter 而我们最想做的，就是利用上述技术为云主机上pebuilder.sh建立一个不死booter，我们知道，现在都流行一键还原和折腾安装系统，老旧的电脑，一折腾错磁盘就费了，又插usb又插光盘的 到现在为止，这种问题依然没有解决，大家还是靠U盘救电脑，其实新的电脑也一样，如果能做到类mac电脑一键网络恢复的功能，它的原理是将网络支持，网络恢复写进了firmware中就好了，在这里提供系统在线恢复所需的环境(这个环境局限受payload大小限制往往只有几M到十几M。)，，如果可以，这一切可以日后可发展到实机上作为linuxpe（不用这个firmware刷机）。因为linux的srs驱动支持很强大。 如果是刷机方式，这种booter是天然刷不死的。除非spi或bios rom坏了。如果是仅放在引导区，只要严格要求镜像市场中的镜像格式审核，也是可以极大程度以免刷死的。 技术原理上，四叶草它们用开源的tiancore和ovmf(qemu)达成。由于变色龙和四叶草实际上就是tiancore模拟内存中的efi加强化了rUEFit引导osx的特化（以引导的形式存在的虚拟firmware，功能面向为引导osx），而linuxboot也面向产出firmware，却跟clover不同的地方在于：（它不面向引导的形式，而面向产出一个能被刷入的rom，linuxboot功能面向于：自动化保留vender中硬件加部分和替换payload的功能），除此之外它们一样。 所以实际上，也可以按照linuxboot的方式在四叶草中里面集成linux和linux rootfs。 由于qemu环境和云主机环境始终是最容易虚拟得到的环境和最方便接确到的实验体，所以。最开始制造for qemu pc3.5,i440fx等的这种不死booter支持最符合现实。 等条件成熟了就动手做一下吧。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
一键pebuilder，实现云主机在线装deepin20beta
本文关键字：deepin云主机版本，在onedrive里装机 国产系统deepin现在已经很精美了，国内很多软硬厂商在慢慢联手uos，。手机os华为方面2020.9月份会发布第一个可用版鸿蒙，这也是一个"uniform os"，最近听说美控台积电又要给华为断供了，但其实技术和生态也是俗物，只要钱慢慢到位，时间都是第二位的，也就没有不可克服的问题，毕竟华为芯片都能自研了，这种从1到2的事情其实反而好办。 我们《minlearnprogrammingv2:选型与实践》作为《minlearnprogramming:理论与实践》的替代与延续，也力在打造一个统一os：mateos,matecloud os，最初定位于从tinycorelinux开始深度定制，最近决定转为基于deepin深度定制，这是一个集成云booter,面向云应用，由客服一体的netdisk backend apps组成的生态。---- 这种集成虚拟机和linux的云booter和kernel exec，真正让rootfs as os container content,使得app和os,subos一个性质都是rootfs。从最开始和源头就自带强烈的虚拟化特性，它类似qubeos,不过qubeos的用处在于利用上述设施制造安全系统，它把联网代码转置入非安全域所以用到vtd，据说还有集成quubeos的librem安全笔记本。而我们的目的在于容器和app container定义和建设。这样deepin os被转换成pure rootfs，放置在rootfs的位置。一个虚拟机上可以运行多份大小os。---- 况且为了这种os下的开发，我们还准备了可视开发和网盘内devops支持（这是后话） 好了不废话了。先在云主机上装上deepinos20beta，经实践，deepin20的界面（非特效）在gd5446下也非常流畅，它的界面效果也是四角圆白色风格，类web还有darkmode。所以放到云主机也是很和谐的效果。 首先我们要创建可用的镜像，还要增强一下《利用onedrive加packerpebuilder实现本地网络统一装机》以来的在od里装机的方案： 创建云主机镜像 利用的是云主机上装黑果系列文章中制造镜像的方法(而非packer结合oss,cos)，在pd中装deepin，开kvm，再启动qemu制造镜像： qemu-img create -f raw deepin20 20G qemu-system-x86_64 -enable-kvm \ -machine pc-i440fx-2.8 \ -cpu Penryn,kvm=off,vendor=GenuineIntel \ -m 5120 \ -device cirrus-vga,bus=pci.0,addr=0x2 \ -usb -device usb-kbd -device usb-mouse \ -device ide-drive,bus=ide.0,drive=MacDVD \ -drive id=MacDVD,if=none,snapshot=on,media=cdrom,file=./20.iso \ -device ide-drive,bus=ide.1,drive=MacDVD1 \ -drive id=MacDVD1,if=none,snapshot=on,media=cdrom,file=./3.iso \ -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=MacHDD \ -drive id=MacHDD,if=none,cache=writeback,format=raw,file=./deepin20.raw \ -device virtio-net-pci,bus=pci.0,addr=0x3,mac='52:54:00:c9:18:27',netdev=MacNET \ -netdev bridge,id=MacNET,br=virbr0,"helper=/usr/lib/qemu/qemu-bridge-helper" \ -boot order=dc,menu=on 手动全盘挂载到/不要自动全盘否则小于64g安装程序不让你过去。以上脚本方案当然也适合windows，我用类似的方案制造了一个winsrvcore2019.gz,对于windows你还需要一个isovirtio-win-0.1.171.iso，上面的3.iso就是。如果是for deepin可以去掉。当然windows需要定制，比如防止ping localhost出现ipv6，disablectlaltdel登录等等。 这样装好的镜像在还原到云主机上或在pd kvm/qemu中运行，都是可以正常联网的。 强化pebuilder.sh 加了一个export tmpGENMIRRORBAK='0'全局变量，即-g开关，直接pebuilder.sh -dd '你的镜像文件地址'，使用-g开关可以生成本地镜像仓库以供上传到你自己的onedrive用 加入了当Downloading basic kernel and rootfs files时： if [[ "$tmpGENMIRRORBAK" == '1' ]]; then bakdir='/tmp/boot/var/log/debian/dists/jessie/main/installer-amd64/current/images' mkdir -p "$bakdir/netboot/debian-installer/amd64" cp "/boot/initrd.img" "${bakdir}/netboot/debian-installer/amd64/initrd.gz" cp "/boot/vmlinuz" "${bakdir}/netboot/debian-installer/amd64/linux" wget --no-check-certificate -qO $bakdir/udeb.list $MIRROR/dists/jessie/main/installer-amd64/current/images/udeb.list fi 接下来的downloading full udeb pkg当然也用这个开关控制。 新的自动化prepare ddessentials： UNZIP='' IMGSIZE='' function PrepareDDessentials(){ if [[ -n "$tmpDDURL" ]]; then echo "$tmpDDURL" |grep -q '^http://\|^ftp://\|^https://'; [[ $? -ne '0' ]] && echo 'No valid URL in the DD argument,Only support http://, ftp:// and https:// !' && exit 1; IMGHEADERCHECK="$(curl -Is "$tmpDDURL")"; IMGTYPECHECK="$(echo "$IMGHEADERCHECK"|grep -E -o '200|302'|head -n 1)" || IMGTYPECHECK='0'; #directurl style,no addon headcheckpass,1 addon typecheckpass to the final [[ "$IMGTYPECHECK" == '200' ]] && \ IMGTYPECHECKPASS_DRT="$(echo "$IMGHEADERCHECK"|grep -E -o 'raw|qcow2|gzip|x-gzip'|head -n 1)" && { # IMGSIZE [[ "$IMGTYPECHECKPASS_DRT" == 'raw' ]] && UNZIP='0' && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS_DRT" == 'qcow2' ]] && UNZIP='0' && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS_DRT" == 'gzip' ]] && UNZIP='1' && sleep 3s && echo -en "[\033[32m gzip \033[0m]"; [[ "$IMGTYPECHECKPASS_DRT" == 'x-gzip' ]] && UNZIP='1' && sleep 3s && echo -en "[\033[32m x-gzip \033[0m]"; [[ "$IMGTYPECHECKPASS_DRT" == 'gunzip' ]] && UNZIP='2' && sleep 3s && echo -en "[\033[32m gunzip \033[0m]"; } # refurl style,(added 1 more imgheadcheck and 1 more imgtypecheck pass in the middle) [[ "$IMGTYPECHECK" == '302' ]] && \ IMGHEADERCHECKPASS2="$(echo "$IMGHEADERCHECK"|grep 'Location: http'|sed 's/Location: //g')" && IMGHEADERCHECKPASS2=${IMGHEADERCHECKPASS2%$'\r'} && IMGHEADERCHECKPASS2="$(curl -Is "$IMGHEADERCHECKPASS2")" && \ IMGTYPECHECKPASS2="$(echo "$IMGHEADERCHECKPASS2"|grep -E -o '200|302'|head -n 1)" && { #sharepoint style,1 addon typecheck pass to the final [[ "$IMGTYPECHECKPASS2" == '200' ]] && \ IMGTYPECHECKPASS_SPT="$(echo "$IMGHEADERCHECKPASS2"|grep -E -o 'raw|qcow2|gzip|x-gzip'|head -n 1)" && { # IMGSIZE [[ "$IMGTYPECHECKPASS_SPT" == 'raw' ]] && UNZIP='0' && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS_SPT" == 'qcow2' ]] && UNZIP='0' && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS_SPT" == 'gzip' ]] && UNZIP='1' && sleep 3s && echo -en "[\033[32m gzip \033[0m]"; [[ "$IMGTYPECHECKPASS_SPT" == 'x-gzip' ]] && UNZIP='1' && sleep 3s && echo -en "[\033[32m x-gzip \033[0m]"; [[ "$IMGTYPECHECKPASS_SPT" == 'gunzip' ]] && UNZIP='2' && sleep 3s && echo -en "[\033[32m gunzip \033[0m]"; } # office365 style,1 addon headercheck and 1 addon typecheck pass to the final [[ "$IMGTYPECHECKPASS2" == '302' ]] && \ IMGHEADERCHECKPASS3="$(echo "$IMGHEADERCHECK"|grep 'Location: http'|sed 's/Location: //g')" && IMGHEADERCHECKPASS3=${IMGHEADERCHECKPASS3%$'\r'} && IMGHEADERCHECKPASS3="$(curl -Is "$IMGHEADERCHECKPASS3")" && \ IMGHEADERCHECKPASS4="$(echo "$IMGHEADERCHECK3"|grep 'content-location: http'|sed 's/content-location: //g')" && IMGHEADERCHECKPASS4=${IMGHEADERCHECKPASS4%$'\r'} && IMGHEADERCHECKPASS4="$(curl -Is "$IMGHEADERCHECKPASS4")" && \ IMGTYPECHECKPASS_OFE="$(echo "$IMGHEADERCHECKPASS4"|grep -E -o 'raw|qcow2|gzip|x-gzip|gunzip'|head -n 1)" && { # IMGSIZE [[ "$IMGTYPECHECKPASS_OFE" == 'raw' ]] && UNZIP='0' && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS_OFE" == 'qcow2' ]] && UNZIP='0' && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS_OFE" == 'gzip' ]] && UNZIP='1' && sleep 3s && echo -en "[\033[32m gzip \033[0m]"; [[ "$IMGTYPECHECKPASS_OFE" == 'x-gzip' ]] && UNZIP='1' && sleep 3s && echo -en "[\033[32m x-gzip \033[0m]"; [[ "$IMGTYPECHECKPASS_OFE" == 'gunzip' ]] && UNZIP='2' && sleep 3s && echo -en "[\033[32m gunzip \033[0m]"; } } [[ "$UNZIP" == '' ]] && echo 'didnt got a unzip mode, you may input a incorrect url,or the bad network traffic caused it,exit ... !' && exit 1; #[[ "$IMGSIZE" -le '10' ]] && echo 'img too small,is there sth wrong? exit ... !' && exit 1; [[ "$IMGTYPECHECK" == '0' ]] && echo 'not a raw,tar,gunzip or 301/302 ref file, exit ... !' && exit 1; else echo 'Please input vaild image URL! '; exit 1; fi } echo -en '\n\nprepare DDessentials ......'; PrepareDDessentials; 加入了定制grub，以提供给用户手动执行pebuilder的机会： sed -i 's/timeout_style=hidden/timeout_style=menu/g' $GRUBDIR/$GRUBFILE; sed -i 's/timeout=[0-9]*/timeout=30/g' $GRUBDIR/$GRUBFILE; 重要的prepare others->the preseed部分： [[ "$UNZIP" == '0' ]] && PIPECMDSTR='wget -qO- '$tmpDDURL' |dd of=$(list-devices disk |head -n1)'; [[ "$UNZIP" == '1' ]] && PIPECMDSTR='wget -qO- '$tmpDDURL' |tar zOx |dd of=$(list-devices disk |head -n1)'; [[ "$UNZIP" == '2' ]] && PIPECMDSTR='wget -qO- '$tmpDDURL' |gzip -dc |dd of=$(list-devices disk |head -n1)'; 和packaging部分： echo -e "\n\033[36m# Packaging \033[0m\n" sleep 2s && echo -en "make a safe wget wrapper to inc --no-check-certificate\n" rm -rf /tmp/boot/usr/bin/wget cat >/tmp/boot/usr/bin/wget<<EOF #!/bin/sh rdlkf() { [ -L "\$1" ] && (local lk="\$(readlink "\$1")"; local d="\$(dirname "$1")"; cd "\$d"; local l="\$(rdlkf "\$lk")"; ([[ "\$l" = /* ]] && echo "\$l" || echo "\$d/\$l")) || echo "\$1"; } DIR="\$(dirname "\$(rdlkf "\$0")")" exec /usr/bin/env wget2 --no-check-certificate "\$@" EOF chmod +x /tmp/boot/usr/bin/wget sleep 2s && echo -en "packaging\n" find . | cpio -H newc --create --quiet | gzip -9 > /boot/initrd.img; [[ "$tmpGENMIRRORBAK" == '1' ]] && echo -en "packaging finished,and all done! auto reboot after 9999s...(if needed, you can press ctrl c to interrupt to bak the repodir under tmp/boot/, then manually reboot to continue)" && sleep 9999s rm -rf /tmp/boot; 还有一些小的修补。 给pe配不死booter的工作还在设想和进行中，可能开始会提供一个较简易的方案，而非与制造开头所提到的云booter一起完成。如果能，当然最好 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
一种设想：在网盘里coding,debuging，运行linux rootfs作全面devops及一种基于分离服务为api的融合appstack新分布式开发设想
本文关键字：Jupyter visual debug，基于网盘backend的ide和snippter空间,debug driven programming，make chrome like visual debug for every lanaguage，make every language a dsl,c系语言学习最好的时代 2020版的macbook要迁移到arm了。这说明，云时代去终端的thin化努力在继续，未来我们的PC和手机会统一(请注意我指的并非是笔记本平板一体机，变形本这些玩意层面上的意思，而是架构和生态的变迁)，而云端始终配合终端变化，走的却是性能不断加强的fat化路子，不光硬件如此，《利用大容量网盘onedrive配合公有云做你的nas及做站》我们已经知道，云开发时代，本地的存储和带宽已经没有了任何优势，有一些资源是本地化不可能得到的，它们只存在于云端。群晖这样的nas跟onemanager+onedrive这样的组合比已经没有了太多优势，会越来越衰败。越来越多的本地的东西迁移到云上，成本也会越来越低，这是软硬一条龙上的变革，最终应用也会越来越倾向利用云计算，这所谓的一条龙，包括os,开发系统，也包括组成应用的各stacks本身，当然也就包括代码托管和开发方式的云化甚至软件的定义（跨多语言组件交互已成必要，中间件和service api原来分布式开发元素上面也有新变化），见下： jupyter for od，让文学编程与网盘后端结合，,just another devops alternatives to cloudwall and github ci/di 首先是代码托管和云IDE方面：在《群晖打造snippter空间》等文章中，我们从云收藏APP的角度讨论了用网盘后端来保存snippter这种特殊内容的方法，就像收藏视频，收藏网页clipper一样，收藏code snippter其实也可以像跟收藏文本一样简单，但相应地，vs 视频之于视步转码云服务md文件之于markdown rendering，对于codesnippter也可以加入复杂的云上再处理（srvside or browser/client side格式化渲染显示,ssr），甚至，更进一步，将它与复杂的netdisk storage backended devops和工程文件组织环境，ci环境，云ide构建环境（云Ide和开发的极大化，就是devops)，。建立起关系， 在《群晖gitlab+docker打造devops》《jupyter设想：enginx,engitor,passone》《cloudwall》当中，我们都介绍过devops:一种将开发上云的手段，这三者都有某种程度的devops支持/都使用某种storage/都建立了某种appstack/都支持一种多种语言，比如，群晖上gitlab是用本地存储作storage,jupyter也是，不过它是一种文学编程工具(librette programming允许我们使用更丰富的文档与注释输助代码)，而且它的devops功能和云IDE很强（最近，jupyter又强化了它的visual debuger功能，使用xeus-python甚至可以可视化高级数据结构和内存对象树,比我们介绍过的《elmlang》这些云可视debug ide还要深层和完善,我们知道elmlang 等visual debug的作用主要是make chrome f12 like visual debug for every language，make every language a visual trigger/action dsl，就像chrome仅能作客端js调试的道理一样，它能使任何编程变得像chrome visual debug和接近web开发调试方式），cloudwall则用couchdb，couchdb不仅是对象数据库还是http应用服务器，由它组成cloudwall这种很内敛却selfly containing gui/http/storage的appstack，它虽然仅支持js(但却可以视js同时为数据和代码，天然可以在线coding和debuging同时mateapp方式客端即服端方式运作 --- 可以说cloudwall是我们见过的第一个完备的mateapp和mateos环境)，jupyter可以多语言，它的功能核心是各种protocols,appstack为类似普通lnmp的web page app(.ipynb),而gitlab，github这种，只有devops中中部分ci/cd功能(github actions,etc..gitpage generation)，离线客户端也是重要的部分，却没有鲜明的在线IDE支持这些方面，线上部分主要为在线hosting代码版本，appstack不限。 但如果能将这种jupyter ide和living coding,debuging做到网盘里，以网盘为存储后端，代替github等coding hosting空间，情况也计会是另一种美好，比如ipynb存在网盘里作为托管codesnipter和工程组织文件，可以直接在网盘里运行语言和部署应用，结合jupyter的visual debug，我们可以在chrome里调用装配了服务端jupyter支持的情况下，我们可以利用服务端rendering，哦不，服务端debuging。这样，网盘后端的jupyter实际承担了，后端language baas，存储，coding,debuging等在线开发全支持。---- 所以，它十分类似cloudwall和github的整体或部分devops相关作用。比如，它还可以用jupyter-book这样的应用达成gitpages,届时，我们甚至可以直接在前端做站,在前端写内容，在前端直接开发调试后端(我们可以将其做成，为每一个app装配一个livedebug，Jupyter backed debugger inside app,比如正常情况下显示程序本身，press esc 会消隐切换到一个visual debug环境)。markdown也直接写样式统一html，我们知道md可以代替html用，这样就有了三个统一，开发调试统一，前后端统一，内容样式又统一。。 利用云booter，在网盘里运行os,作全面devops 实际上，我们知道，除了语言后端和devops工具，更强大全面的devops需要docker或虚拟机来参与构建，虚拟机和docker始终显得太重，在《一键pebuilder安装deepin20中》我们提到一句后话：为了mate os下的开发，我们还准备了可视开发和网盘内devops支持，这就是整个文档集《minlearnprogrammingv2》part1提出的一种云booter：它更轻量，工作原理类似系统级的虚拟机，在boot和firmware级集成虚拟机支持，自带Linux kexec protocol，可以在启动booter时启动多个资源允许内的rootfs as os container content,使得app和os,subos一个性质都是rootfs。 ps:如果说在网盘里运行jupyter是对minlearnprogrammingv1 时代engitor概念体的强化，那么新的pebooter则是对v1时代diskbios的概念体强化（目前我们仅做到网盘云装机）。之前我们在文章中研究了 colinux,openvz,lxd等虚拟和多开方案并企图covering all硬件平台包括实机，但我们现在正式转到云boot上来并局限在仅云主机，天然多os和多开类colinux的rootfs级虚拟化。更适合云主机。 最后，当云开发，云devops,云代码托管都被做在了云上，再加上这里的云os，这所有加起来的好处是，我们可能并不需要一台真正的pc作开发和应用，不光内容同步可以整包打走。，甚至可以真正做到去PC戒电脑，这个clientless仅指去x86 pc化(比如我们可以选择更省能的arm平板加一台x86云上装有mateos和上面jupyter,云booter的服务器作mate pc。实现去pc化)。 甚至，当这一切发生变化的时候，云化开发方式和appstack也要经过云化： 我们知道，较之cloudwall，其单一性也是其自身的优势也同样是其明显局限，jupyter支持的多语言加网盘后端模拟的cloudwall更符合通用的情形，但是要达到用jupyter精确模拟cloudwall式mateapp的效果，需要更多额外的工作。 其中之一是需要统一的api定义和调用方式。 matecloud virtual appliance:一种统一web appdev和native appdev,基于api分离及服务组件化的融合分布式appstack 在《hyperkit:一个full codeable,full dev support的devops及cloud appmodel》中我们提到“一种可能行得通的appmodel设想：P2p 客服同体，只需sync api结果即可的app”，在《利用开发tcp思路来开发web》，我们提到利用wpcore as service，在《利用大容量网盘onedrive配合公有云做你的nas及做站》中我们见识到腾讯云函数serveless,这其实就是以前组件技术和远程方法调用，及webservices，serverless只不过倾向更多指免运维的极大化。我们还发现reactive page/pwa这种js库，缓存页面在客户端，反应很快。类桌面效果。因为它是使用web api的，前后端通过设置api分离。所以客户端html和静态资源可以缓存。 PS:甚至于我们上面提到的这种c++ xeus debug protocols，它实际上就是api（应用处）和语言接口（语言处）的一种类似体，我们知道，web天然就是服务化分布式的，web编程的实质在于service化，和service调用，面向产生和使用各种service api，这是一种与本地api开发和分发完全不一样的形式，是不同内存模式的多语言处理异构系统交互的方式，涉及到多语言和调用组件定义。然而我们现在的web是将html与后端逻辑形成一种组成app的stack，这样，实际上导致了界面和业务逻辑不可分，也导致了云服务应用中，客服cs/bs不可分，失去了streaming html as page gui的好处 ---- 真正正确的做法，应该是仅把html分离作为gui content only不集成到appstack as gui，采用js/reactive的做法，后端与前端完全通过service api分离，后端定义出业务逻辑api用一个rpc表达出各种外部服务接口，供前端（它只应是一个js/html reactive客户端的程序）使用，web api与web服务，使前后端真正分离,将界面渲染全面放到客户端reactive pages，没有任何服务端内嵌html渲染html的逻辑。整个应用用传统web的mvc来解决，比如onemanager的类比物：cloudreve就用了这种技术，如果onemanager来采用，展示速度又会提升很多。 这种分离客服reactive page纯客户端渲染方式，像极了native app，而本地开发其实也可以用这种方法。为前端调用定义出api。后端透出api，又可将本地开发和远程开发统一一个模型：比如实际上deepin的qt+go backend的deepin ui appstack也是这样的思路。除了界面，存储也可以以不掺入任何界面渲染的方式进行，仅是另外服务区导入进来的api。这就是各端分离。云函数纯api化，单独开发调用，通过rpc交互的思路，又迎合现在跨多语言开发的方式。 如果结合上面的mateos cloud boot技术，可以将每个这种app欠嵌一个vm，做成virtual appliance。只有web真正跨三端如果所有界面都用js/reactive呈现可以达到原生渲染的效率，这样就模拟了go，且不再局于Go和 go app 是最好的virtual applicane选型的说法. 本地app和远程app融合的最高境界是microservice app，即不光数据解决了sync，程序逻辑本身也一体化。这其实要跟mateos相协作。见打造一个全融合的云《一种追求高度融合，包容软硬方案的云主机集群，云OS和云APP的架构全设计》。 本文注定晦涩难懂，这是一种需要操作系统改革协作的工程，所以为此我们提出了mateos和直到mateapps的全设想，一个建立virtual applicance支持，一个建立appstack支持，相互绝配。这种分离也为编程教育划分了新的实践方向，我们会另写一篇《实践即工程与反工程》作序言放在《软件即抽象》下。因为实践所需要的工程规模选型需要同时涵盖本地开发和web开发域，搞懂这里的技术本质和经过几个大小这种工程，就可以由纯学习上升到参加工作所需能力的实践量了。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
利用onedrive加packerpebuilder实现本地网络统一装机
本文关键字：bash line string to array, sed 按匹配次数替换，sed替换指定次数的某字符串,bash变量替换，即时赋新值，bash 数组下标变量 在《利用installnet制作一个云装机packerpe》1,2中我们谈到了packerpebuilder.sh用于云主机装机的用处，它的原理是产生一个基于d-i的pe，然后这个pe会使用当初封装的dd url去网络下载镜像并dd到硬件，在《利用od做站和nas》我们谈到了其与终端作pcmate,mobilemate的那些方面（这个系列只讲了做站，即配合client pc as page server mate的方面---想象一下，在客户端我们可以用servering pages，只是拥有了网盘backend的page server app才真正使远程和本地成为一对mates，产生本地远程合一的mate app，未来我们还会讲配合client pc作离线下载，网盘转存等mateable的方面），今天，我们将用onedrve结合packerpebuilder实现本地也能像云主机一样装机，使远程成为本地装机app，实际上这个思路自packerpebuilder一开始就有了，只是一直没有找到合适能用的网盘。直到对onedrive的直链有了研究之后，才有了本文。 不废话了 前置改动 把tmpmirror也消除了。调整了一些注释，如整合checkdeps和selectmirror为prepare prerequisites，selectmirror经过重构变成select1stvalidmirrorfrom3(): function Select1stValidMirrorFrom3(){ [ $# -ge 1 ] || exit 1 declare -A MirrorTocheck MirrorTocheck=(["Debian0"]="" ["Debian1"]="" ["Debian2"]="") echo "$1" |sed 's/\ //g' |grep -q '^http://\|^https://\|^ftp://' && MirrorTocheck[Debian0]=$(echo "$1" |sed 's/\ //g'); echo "$2" |sed 's/\ //g' |grep -q '^http://\|^https://\|^ftp://' && MirrorTocheck[Debian1]=$(echo "$2" |sed 's/\ //g'); echo "$3" |sed 's/\ //g' |grep -q '^http://\|^https://\|^ftp://' && MirrorTocheck[Debian2]=$(echo "$3" |sed 's/\ //g'); for mirror in $(echo "${!MirrorTocheck[@]}" |sed 's/\ /\n/g' |sort -n |grep "^Debian") do CurMirror="${MirrorTocheck[$mirror]}" [ -n "$CurMirror" ] || continue # CheckPass1='0'; # DistsList="$(wget --no-check-certificate -qO- "$CurMirror/dists/" |grep -o 'href=.*/"' |cut -d'"' -f2 |sed '/-\|old\|Debian\|experimental\|stable\|test\|sid\|devel/d' |grep '^[^/]' |sed -n '1h;1!H;$g;s/\n//g;s/\//\;/g;$p')"; # for DIST in `echo "$DistsList" |sed 's/;/\n/g'` # do # [[ "$DIST" == "jessie" ]] && CheckPass1='1' && break; # done # [[ "$CheckPass1" == '0' ]] && { # echo -ne '\njessie not find in $CurMirror/dists/, Please check it! \n\n' # bash $0 error; # exit 1; # } CheckPass2=0 ImageFile="SUB_MIRROR/dists/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz" [ -n "$ImageFile" ] || exit 1 URL=`echo "$ImageFile" |sed "s#SUB_MIRROR#${CurMirror}#g"` wget --no-check-certificate --spider --timeout=3 -o /dev/null "$URL" [ $? -eq 0 ] && CheckPass2=1 && echo "$CurMirror" && break done [[ $CheckPass2 == 0 ]] && { echo -ne "\033[31mError! \033[0minitrd.gz not find in $CurMirror/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/! \n"; bash $0 error; exit 1; } } MIRROR=$(Select1stValidMirrorFrom3 'http://httpredir.debian.org/debian' 'http://www.shalol.com/cn/d/debian' 'http://http://archive.debian.org/debian') [ -n "$MIRROR" ] && echo -en "Select Mirror ......:" && echo -en "[\033[32m ${MIRROR} \033[0m]\n" || exit 1 主体改动 整合prepare parepare dist files包括downloading basic kernel and rootfs files（将它提前，逻辑更合理。）和downloading repo pkgs files，，以及接下来的PrepareDDessentials(其原来内部下载deb的逻辑整合到与下载full udeb一起)，，并将它们都变成可复用的函数和函数调用buildrepo()和PrepareDDessentials(). prepare parepare dist files与prepare others是并列的：前三者是大资源文件，后三者是小参数文件，将二者中间延时变量变成2s，各内部延时3s（内部还去掉了细节方面，肯定情况下的一些echo输出，改为直接exit 1，改为由主要的几句话来echo，界面输出更清），共5s wget要调用ssl client才能tls certificate已完善，buildrepo()更强大，支持sed "s/(+|~)/-/g"处理链接中的+号和~号(tcb上的onemanager不支持这类特殊符号)，和更强大更逻辑清楚的拉取安装deb pkgs支持: IncPkgrepo='1' declare -A OPTPKGS OPTPKGS=( ["libc1"]="pool/main/g/glibc/libc6_2.28-10_amd64.deb" ["fmtlibc"]="xz" ["binlibc"]="" ["common1"]="pool/main/g/gnutls28/libgnutls30_3.6.7-4+deb10u3_amd64.deb" ["common2"]="pool/main/p/p11-kit/libp11-kit0_0.23.15-2_amd64.deb" ["common3"]="pool/main/libt/libtasn1-6/libtasn1-6_4.13-3_amd64.deb" ["common4"]="pool/main/n/nettle/libnettle6_3.4.1-1_amd64.deb" ["common5"]="pool/main/n/nettle/libhogweed4_3.4.1-1_amd64.deb" ["common6"]="pool/main/g/gmp/libgmp10_6.1.2+dfsg-4_amd64.deb" ["fmtcommon"]="xz" ["bincommon"]="" ["busybox1"]="pool/main/b/busybox/busybox_1.30.1-4_amd64.deb" ["fmtbusybox"]="xz" ["binbusybox"]="bin/busybox" ["wgetssl1"]="pool/main/libi/libidn2/libidn2-0_2.0.5-1+deb10u1_amd64.deb" ["wgetssl2"]="pool/main/libp/libpsl/libpsl5_0.20.2-2_amd64.deb" ["wgetssl3"]="pool/main/p/pcre2/libpcre2-8-0_10.32-5_amd64.deb" ["wgetssl4"]="pool/main/u/util-linux/libuuid1_2.33.1-0.1_amd64.deb" ["wgetssl5"]="pool/main/z/zlib/zlib1g_1.2.11.dfsg-1_amd64.deb" ["wgetssl6"]="pool/main/o/openssl/libssl1.0.0_1.0.1t-1+deb8u8_amd64.deb" ["wgetssl7"]="pool/main/o/openssl/openssl_1.0.1t-1+deb8u8_amd64.deb" ["wgetssl8"]="pool/main/w/wget/wget_1.20.1-1.1_amd64.deb" ["fmtwgetssl"]="xz" ["binwgetssl"]="usr/bin/wget" ["webfs1"]="pool/main/libf/libffi/libffi6_3.2.1-9_amd64.deb" ["webfs2"]="pool/main/m/mime-support/mime-support_3.62_all.deb" ["webfs3"]="pool/main/libu/libunistring/libunistring2_0.9.10-1_amd64.deb" ["webfs4"]="pool/main/w/webfs/webfs_1.21-ds1-12_amd64.deb" ["fmtwebfs"]="xz" ["binwebfs"]="" ) function buildrepo(){ if [[ "$IncPkgrepo" == '1' ]]; then echo -e "Downloading full udebs pkg files..... [\033[32m ${MIRROR}/dists/jessie/main/debian-installer/binary-amd64/Packages.gz \033[0m]\n" repodir='/tmp/boot/var/log/debian' mkdir -p $repodir udeburl=".*pool\/main\(.*\)udeb.*" wget --no-check-certificate -qO- "$MIRROR/dists/jessie/main/debian-installer/binary-amd64/Packages.gz" |gunzip -dc|sed "/$udeburl/!d"|sed "s/Filename: //g"|while read line do path=${line%/*} mkdir -p $repodir/$path file=${line##*/} wget --no-check-certificate -qO $repodir/$path/$(echo $file|sed "s/\(+\|~\)/-/g") $MIRROR/$line done mkdir -p $repodir/dists/jessie/main/binary-amd64/ mkdir -p $repodir/dists/jessie/main/debian-installer/binary-amd64/ mkdir -p $repodir/dists/jessie/main/installer-amd64/current/images/ wget --no-check-certificate -qO $repodir/dists/jessie/Release $MIRROR/dists/jessie/Release wget --no-check-certificate -qO $repodir/dists/jessie/main/binary-amd64/Release $MIRROR/dists/jessie/main/binary-amd64/Release wget --no-check-certificate -qO $repodir/dists/jessie/main/debian-installer/binary-amd64/Release $MIRROR/dists/jessie/main/debian-installer/binary-amd64/Release wget --no-check-certificate -qO $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz $MIRROR/dists/jessie/main/debian-installer/binary-amd64/Packages.gz; \ orisize=$(cat $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz | wc -c); \ orimd5=$(md5sum $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz| awk '{ print $1 }'); \ orisha1=$(sha1sum $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz| awk '{ print $1 }'); \ orisha256=$(sha256sum $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz| awk '{ print $1 }'); \ gunzip -c $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz > $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages; \ rm -rf $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz; \ sed -i "s/\(+\|~\)/-/g" $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages; \ gzip -c $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages > $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz; \ rm -rf $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages; \ cursize=$(cat $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz | wc -c); \ curmd5=$(md5sum $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz| awk '{ print $1 }'); \ cursha1=$(sha1sum $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz| awk '{ print $1 }'); \ cursha256=$(sha256sum $repodir/dists/jessie/main/debian-installer/binary-amd64/Packages.gz| awk '{ print $1 }') toreplace="main\/debian-installer\/binary-amd64\/Packages.gz" linenoarray=($(grep -n $toreplace $repodir/dists/jessie/Release |cut -f1 -d:)) sed -i ${linenoarray[0]}s/$orimd5/$curmd5/ $repodir/dists/jessie/Release sed -i ${linenoarray[0]}s/$orisize/$cursize/ $repodir/dists/jessie/Release sed -i ${linenoarray[1]}s/$orisha1/$cursha1/ $repodir/dists/jessie/Release sed -i ${linenoarray[1]}s/$orisize/$cursize/ $repodir/dists/jessie/Release sed -i ${linenoarray[2]}s/$orisha256/$cursha256/ $repodir/dists/jessie/Release sed -i ${linenoarray[2]}s/$orisize/$cursize/ $repodir/dists/jessie/Release wget --no-check-certificate -qO $repodir/dists/jessie/main/installer-amd64/current/images/udeb.list $MIRROR/dists/jessie/main/installer-amd64/current/images/udeb.list chmod -R 0644 $repodir/ fi echo -e "Downloading optional deb pkg files...... [\033[32m ${MIRROR}/dists/jessie/main/binary-amd64/Packages.gz \033[0m]\n"; for pkg in `echo "$1" |sed 's/,/\n/g'` do [[ -n "${OPTPKGS[$pkg"1"]}" ]] && { for subpkg in $(echo "${!OPTPKGS[@]}" |sed 's/\ /\n/g' |sort -n |grep "^$pkg") do cursubpkgfile="${OPTPKGS[$subpkg]}" [ -n "$cursubpkgfile" ] || continue cursubpkgfilepath=${cursubpkgfile%/*} mkdir -p $repodir/$cursubpkgfilepath cursubpkgfilename=${cursubpkgfile##*/} cursubpkgfilename2=$(echo $cursubpkgfilename|sed "s/\(+\|~\)/-/g") wget --no-check-certificate -qO $repodir/$cursubpkgfilepath/$cursubpkgfilename2 $MIRROR/$cursubpkgfile; \ [[ "${OPTPKGS["fmt"$pkg]}" == "tar" ]] && ar x $repodir/$cursubpkgfilepath/$cursubpkgfilename2 data.tar.gz && tar xzf data.tar.gz && rm -rf data.tar.gz [[ "${OPTPKGS["fmt"$pkg]}" == "xz" ]] && ar x $repodir/$cursubpkgfilepath/$cursubpkgfilename2 data.tar.xz && xz -d data.tar.xz && tar xf data.tar && rm -rf data.tar done [[ -n "${OPTPKGS["bin"$pkg]}" ]] && mv -f /tmp/boot/${OPTPKGS["bin"$pkg]} /tmp/boot/${OPTPKGS["bin"$pkg]}2 # [[ ! -f /tmp/boot/${OPTPKGS["bin"$pkg]}2 ]] && echo 'Error! $1 SUPPORT ERROR.' && exit 1; } done } buildrepo libc,common,busybox,wgetssl; PrepareDDessentials()也更强大，支持sharepoint和office365个人的302跳转风格，强化《利用installnet制作一个云装机packerpe》2中关于仅支持office365style相关方面功能 --- 其实sharepointstyle和office365 style也可自动公判断，但是我不想折腾了。 UNZIP='' DDURL='' OFFICE365STYLE='0' SHAREPOINTSTYLE='1' function PrepareDDessentials(){ if [[ -n "$tmpDDURL" ]]; then echo "$tmpDDURL" |grep -q '^http://\|^ftp://\|^https://'; [[ $? -ne '0' ]] && echo 'No valid URL in the DD argument,Only support http://, ftp:// and https:// !' && exit 1; IMGHEADER="$(curl -Is "$tmpDDURL")"; IMGTYPE="$(echo "$IMGHEADER" | grep -E -o '200|302')" || IMGTYPE='0'; # [[ "$IMGTYPE" -ne '0' ]] && echo 'not a raw,tar,gunzip or 301/302 ref file, exit ... !' && exit 1 || { [[ "$IMGTYPE" == '200' ]] && IMGHEADERCHECKPASS2="$(echo "$IMGHEADER" |grep -E -o 'raw|qcow2|gzip|x-gzip')" && { [[ "$IMGTYPECHECKPASS2" == 'raw' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'qcow2' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gzip \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'x-gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m x-gzip \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'gunzip' ]] && UNZIP='2' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gunzip \033[0m]"; } [[ "$IMGTYPE" == '302' && "$OFFICE365STYLE" == '1' ]] && { \ IMGHEADERCHECKPASS2="$(echo "$IMGHEADER" |grep 'Location: http'|sed 's/Location: //g')" && IMGHEADERCHECKPASS2=${IMGHEADERCHECKPASS2%$'\r'} && \ IMGHEADERCHECKPASS3="$(curl -Is "$IMGHEADERCHECKPASS2" |grep 'content-location: http'|sed 's/content-location: //g')" && IMGHEADERCHECKPASS3=${IMGHEADERCHECKPASS3%$'\r'} && \ IMGTYPECHECKPASS2="$(curl -Is "$IMGHEADERCHECKPASS3" | grep -E -o 'raw|qcow2|gzip|x-gzip|gunzip')" && { [[ "$IMGTYPECHECKPASS2" == 'raw' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'qcow2' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gzip \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'x-gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m x-gzip \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'gunzip' ]] && UNZIP='2' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gunzip \033[0m]"; } } [[ "$IMGTYPE" == '302' && "$SHAREPOINTSTYLE" == '1' ]] && { \ IMGHEADERCHECKPASS2="$(echo "$IMGHEADER" |grep 'Location: http'|sed 's/Location: //g')" && IMGHEADERCHECKPASS2=${IMGHEADERCHECKPASS2%$'\r'} && \ IMGTYPECHECKPASS2="$(curl -Is "$IMGHEADERCHECKPASS2" | grep -E -o 'raw|qcow2|gzip|x-gzip|gunzip')" && { [[ "$IMGTYPECHECKPASS2" == 'raw' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'qcow2' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gzip \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'x-gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m x-gzip \033[0m]"; [[ "$IMGTYPECHECKPASS2" == 'gunzip' ]] && UNZIP='2' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gunzip \033[0m]"; } } [[ "$UNZIP" == '' ]] && echo 'didnt got a unzip mode, exit ... !' && exit 1; [[ "$DDURL" == '' ]] && echo 'didnt got a ddurl, exit ... !' && exit 1; [[ "$IMGTYPE" == '0' ]] && echo 'not a raw,tar,gunzip or 301/302 ref file, exit ... !' && exit 1; # } else echo 'Please input vaild image URL! '; exit 1; fi } echo -e 'prepare DDessentials ......'; PrepareDDessentials; sleep 3s 使用方法 中途提示备份,会给你30s上传/tmp/boot/var/log/debian仓库到onedrive或其它服务器创建镜像，。 [[ "$tmpINSTANTWITHOUTVNC" == '0' ]] && echo "finished, auto reboot after 30s...(if needed, you can press ctrl c to interrupt to bak the repodir:$repodir, then manually reboot to continue)";sleep 30s preseed中的mirrorhost换成你的od上传地址。 然后就然后了。。。 未来，我们要往packerpebuilder中集成不死booter。这样装机永远都不会因为抹了第一个硬盘哭了。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
利用onemanager配合公有云做站和nas（2）:在tcb上装om并使它变身实用做站版
本文关键字：tcb上安装onemanager,onemanger实用做站 在《利用大容量网盘onedrive配合公有云做你的nas及做站》中，我们初步谈到了使用onemanager配合云函数或云主机做站的投入和尝试，前文说到不能在腾讯cloudbase上安装onemanager，但实际上经过尝试发现是可以的： 注意：云函数产品建议使用包月免费或包月套餐尝试。按量如果控制不好，可能会因为代码问题或外部攻击造成高额费用，比如腾讯scf按量下如果免费额度用完，24小时才停机不会立马停，而且它的计费即使你帐号没钱也会往负了扣，极可能超支。包月则不会有预算超支。 所以我们接下来讲解在包月免费的tcb上安装它： 在tcb上安装onemanager 首先，从http://github.com/qkqpttgf/OneManager-php下载代码，先不上传到cloudbase空间，本地修改platform/tencentscf.php的GetGlobalVariable($event){...}函数体中的$_GET = $event['queryString']为$_GET = $event['queryStringParameters']，这样?admin等参数传递就正确了。然而程序还是得不到入口index.main_handler，直接使用cloudbase后台的新建函数只能用index.man作入口，手动修改入口可以执行，但程序会进一步得不到环境变量，我们可以统一使用cloudbase cli命令行工具全面定制： cloudbase cli是一个nodejs程序。按腾讯产品文档在本地安装后tcb login --key登录，填入你的用户access keyid和keysecret，在本地做一个待上传目录，在此目录下写如下内容的cloudbaserc.json，同时准备子目录：functions/myonemanager/下放经过上面修改的onemanager代码，到待上传目录(你也可以建一个目录myonemanager，把om源码和cloudbaserc.json统统放进去不用建functions/myonemanager子目录,但是下面cloudbaserc.json中的functionroot要改为../)： { "envId": "你的环境", "functionRoot": "functions", "functions": [{ "name": "myonemanager", "timeout": 6, "runtime": "Php7", "installDependency": true, "handler": "index.main_handler有了这个就不用改入口了", "envVariables": { "Region":"ap-shanghai", "SecretId":"你的腾讯accesskeyid", "SecretKey":"你的腾讯accesskeysecret", "admin": "你要定义给后台的密码，明文", "sitename": "站点名，找一个在线base64转码后，将结果填这", "hideFunctionalityFile": "1", "disableChangeTheme": "1", "passfile": "密码文件名", "theme": "主题名", "timezone": "8", "disktag": "盘名1|盘名2", "盘名1": "{\"Drive_custom\": \"on\",\"Drive_ver\": \"CN\",\"client_id\": \"你的azure app portal for onemanager的client app id明文\",\"client_secret\": \"你的azure app portal for onemanager的client app secretbase64明文找一个base64转成结果填这\",\"diskname\": \"明文找一个base64转成结果填这\",\"domain_path\": \"明文找一个base64转成结果填这，形式是域名1:/目录1|域名2:/目录2......\",\"refresh_token\": \"看接下来手动获取方法\",\"token_expires\": 9999999999}", "盘名2": "{同盘1生成方式}" } }] } 可以看到盘名1后面的参数是一个字串，然而它本身也是个json，将json转成字串供cloudbase识别的方法是将所有"都转义一下，如果你嫌麻烦实在想图方便，可以在正常非cloudbase区或vps上直接搭建一个onemanager,注册盘，然后将结果填到上面。上面的clientid和secretid，正常方式安装od是自动的，但其实你也可以手动https://portal.azure.cn/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps去生成，我这里是互联，新注册->任何组织目录中的帐户,多租户->重定向url:web,https://scfonedrive.github.io，这里可以直接看到client id了。看左边列，api权限不用设置，证书和密码->新客户端密码，期限永久，就看到secret了。至于refresh token，也可以从https://service-36wivxsc-1256127833.ap-hongkong.apigateway.myqcloud.com/release/scf_onedrive_filelistor手动得到。token_expires填10位9。 cloudbaserc.json准备完毕，最后cd到这个目录，cloudbase functions:deploy，这样你就得到了一个完全手动和程序化的安装方式，后台改变256m到128m,触发路径/或/xx不能是/xx/结尾，以后deploy，提示覆盖直接确认即可。 更多让onemanager实用做站的考虑 我们知道，云函数主要是处理api结果的传送，在这里不能传递大量数据，保证一次http所有结果在最短的ms里完成，否则按调用次数和调用时长及内存占用的云函数会相应产生相对高的花费，查云函数后台，确保每次2ms内的调用是合理和正常的。故onedrive和托管onemanager等程序的空间（这二者最好是同一地域的，比如世纪互联配国内空间，国际版配港区空间）对提高调用速度至关重要，有些onedrive列表程序支持，前后端分离，云函数纯粹后端只返回api结果不包前端渲染。api速度快(列文件很快)如fodi. 处理静态资源问题和定制模板： 由于od是一个特殊的程序，它定位于网盘文件列表而非带资源的网站展示，它绑定的工作域名下，每一个路径，如果不是显式的?setup这种参数，就是文件调用，因此，它对所有js,css的引用，都是外部的(如果发现网页慢，将它换到快点的cdn地址)。这也是为了上面说的一次request/respon能尽快调用完成，所以od的templates都是不带静态asserts的。------ 所以并不推荐将静态template资源放在代码theme下，然后根据判断它是不是网盘文件进一步处理。 谈到od的templates,其实它也是网页模板技术的运用（本质就是定义一系列开头结尾组合形式的模板变量块，然后替换），你可以查看已有template自己写一个比如最简单的那个nexmoe1.html，，模板体逻辑通常是这样的：开头icon处理块，管理相关的style，前端样式style块,外部css和jss引用，渲染omf，md文件的逻辑块(require一个maked js然后根据md content在页面直接render)，。列文件和目录的逻辑（其实又包括div逻辑块，js逻辑块）,blaaaa.....。 加速和cdn： 我们知道网站速度至关重要。不光对用户对运营也是如此。要实用做站的话，必须要配cdn。对于cdn加速，比如要求文件静态化为各个url路径为目录名的目录下的index,html。onemanager有没有相关方面的支持呢 od是带缓存的。主要是存取到云函数backend空间的system temp目录中。这样列文件和目录的时间会相对变少。程序效果和体验会最佳。od内部对text文件(包括markdown)都是有1800秒缓存的。这个过程在common.php中，查看fetch files,render list主要函数，gethiddenpass()等类似函数。 对于md，上面说到它是在客户端通过client js来渲染从服务端拉取下来的内容的（如果发现大量md的网站慢，有可能这个js处在慢速cdn上，换个），，对于html则是跟md一样直接下载并output不经过主题渲染处理，相当于部署了一个静态页面。 本来它是在客户端生成的。其实在服务端也可完成md,比如下载一个php的渲染器mdparser.php，再在index.php中include 'mdparser.php';common.php中在对应headmd处理位置的地方作修改： $parser = new HyperDown\Parser; $headmd = str_replace('<!--HeadmdContent-->', $parser->makeHtml(fetch_files(spurlencode(path_format(urldecode($path) . '/head.md'),'/'))['content']['body']), $tmp[0]); $tmp = splitfirst($html, '<!--MdRequireStart-->'); $html = $tmp[0]; $tmp = splitfirst($tmp[1], '<!--MdRequireEnd-->'); 在服务端生成html作为api结果返回会稍微增加api时间，但结果更合理。你可以进一步把渲染好的html结果保存在cache中对应md地址的子目录index.html（而不是原来的raw md content）中，然后下回fetch到这个md地址，直接取cache，按处理html的方式，直接render。这样的“全站伪静态”对cdn也是有用的。 你也可以修改refreshcache的逻辑，od有一个refresh cache，它是先切换到当前目录下就refresh哪个目录的cache。且只工作在手动管理模式下，其实你可以把它做成自动静态化的，浏览到对应md位置就生成对应index.html到cache/md命名子目录下。然后在后台做一个一键md全站生成html到cache静态化按钮和功能。或者生成到cloudbase的存储中。---- 已经有这样的程序了，静态网站生成器作为云函数，生成静态文件到oss，云存储。像极了自动化的github page action。 ps:。一般来说，根据我的“硬件使用3年即报废，不应超过500元/年，总共应投入1500，超过这个都是这个时代的奢侈品“的嘴强说法，如果做站用的虚拟资产也可归其中，则3年期的1t互联或淘宝买的个人/家庭office365官方版+3年最低配的1h1m云主机或虚拟主机也正好落入这个区间(office365已改为microsoft365,感觉国际个人/家庭版的没有国际商用版的快，优点是前者多了个文件vault库)。可惜bat等不支持终身制虚拟主机（onemanager需要php curl扩展）或终身制弹性云主机,否则这就是一种不虐心云主机的省事投资了。 在前面，我们为oc增加了wp功能和note功能，现在为od增加静态html功能，同样基于做站和静态化考虑，现在，我们对od开刀了。可能最终，我们要类群晖的dsm based on a netdisk,将od类似的理念打造一个mineportal os，而不仅仅停留在一个file lister，这是比云主机黑群还实用的方案，比如myportalnew: email是必须的+类似微信自托管的chat app+file sync+mateos app那些。。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
一个netdisk storage backend app webos和增强的全功能网站云设想
本文关键字：利用网盘空间,network filesystem代替静态网站空间,做成静态网站的动态模块,利用v2ray,nginx给onedrive+onemanager做自动cdn,利用网盘代替函数计算 在前面《利用大容量网盘onedrive配合公有云做你的nas及做站》我们说到用网盘空间达成网站云和用网盘做附件床，一般这样的云网站方案中，静态html都是用oss做的空间。但其实配合oneindex等程序，网盘也可以存放md资源。直接in memeory servering md pages成html，这样网盘+云函数空间或ecs，就不仅可作为附件床了，甚至可以作为静态网页生成器空间。达到全功能网站云的效用（配合下面的内容加速甚至可以代替cdn）。 包括上文在内，我们所有的努力是让网站app和网站资源，聚合进一个网盘 as nas中，网盘网站通过客户端挂载后，可以本地文件形式一个一个编辑和同步，也可以直接在远程编辑md，类似mediawiki和gitpages在线编辑。网页和附件可以统一打包备份。服务于你的中心nas库建设(onedrive as nas)，一套下来可谓省事不少。 利用网盘直接展示和写作静态网站，自建静态展示空间 依然用前文的onemanger来举例，我们可以把静态网站的md文件按树形层次文件夹组织好，文件夹名即为文档标题（当然可以稍为处理一下，标题中不要出现特殊符号），然后一个文档文件夹中放一个head.md，它里面放主要文档内容因为它主要是在页面前面显示的。如果你的文档文件夹只有此内容部分，那么接下来显示的就是一栏只有一个head.md文件的附件列表，如果你的文档文件夹中还有其它下载资源和资源需要说明，可以在这里上传（或通过网盘上传）再放一个read.md，read.md效果会出现在页面下面，，如果是非文档文件夹和非文档子文件夹，就光放下载资源就可以了，一个页面除了文档部分就是附件列表，附件列表就相当于做成静态网站的动态模块（评论模块处）。整站主页嘛，就在网盘根下放一个head.md。 这样下来，一个利用网盘展示markdown网站文档的效果就达成了。 你可能需要定制一下把head.md和readme.md隐藏这样效果更好，在后台设置就好了。Pagenatior可能也需要处理一下更美观，—— 如果一文件夹下有太多下载资源或文档子文件夹的话。你当然还可以再定义主题风格。 网站可能还需要一些强化，因为纯粹依赖网盘没有本地部分，可能网盘一旦挂了，网站就空了，所以需要提供虚拟目录的功能，即网盘程序会挂载本地目录作为跟外来网盘同级的文件夹展示，你可以在这里放一个由markdown组成的备份网站（或者指定部分文件夹自动从网盘缓存到本地servering，如markdown网站所在文件夹然后挂载，后台有某个开关切换展示本地缓存的网站。）。如https://github.com/reruin/sharelist支持虚拟目录。可以本地和盘内共享一个域名。 内容加速，自备cdn onedrive官方的外链速度由于在港区和新加坡，跟轻量机的带宽一样，也分闲时忙时，深夜凌晨快，白天很慢。那么有没有办法为网站加速吗，如果你托管onemanager的云主机是港区轻量再好不过，流量充足30M带宽。虽然转发是建立在轻量线路其实也分闲时忙时的提前下，但假设轻量线路比onedrive线路好，至少可以一试。 用二种方案，在服务器nginx加速，在客户端v2ray加速。服务端加速就是通过利用Nginx反代加速Oneindex，让Onedrive流量通过服务器中转，解决Onedrive在线播放视频下载慢等的问题。Nginx处和Onemanager处理处(支持sharepoint.com的反代)都要设置一下， 客户端v2ray嘛。不用介绍了吧。话说，如果v2ray也像网盘api一样。可以通过编程方式给内容加速就好了。提供api就接入了编程。 利用网盘代替函数计算,直接托管云程序cloud demo，自建脚本空间 我们知道网盘自身没有计算能力，必须要搭配函数计算或云主机调用其开放api才能调用其中数据为建站所有或用于nas目的，但如果在网盘中托管的是非静态数据，而是程序或脚本。然后考虑通过搭配云函数或云主机去运行它呢？？vs 渲染静态md成html，这里是运行脚本，呈现结果界面。比如，可以用于展示自己收藏的脚本并让用户点击launch it看到运行结果。形成自己的online demo repo —— 类似我们之前的折腾《使用群晖作mineportalbox（2）：把webstation打造成snippter空间》。脚本形式放网盘，还可以一同参与备份（网站数据和代码一起备份）。 这种方案有点接近让网盘具备云函数能力，与jupyter和herku容器这样的东西重复。这些都是利用脚本语言的runtime做程序执行机制的变体技术，比如，云函数计算实际上是将语言 Runtime 本质上是一个 HTTP Server, 再为web建立api机制而已（api,zeromq，消息件,restful也可以）。—— 当然，接近归接近，其本质并非如此，我们始终用的是网盘的存储能力它本身并不具备运行能力。只是可以作为一种折腾方向，不过值得一试，比如通过在onemanager中增加相关功能达成。 ————— 最近转到腾讯云了。发现其优惠力度和实用性比阿里云还大。尤其是618或1111，1212时的新购1到2折，所有主机还是100%CPU和5M带宽，企业用户更是优惠，这实在比抠抠嗖嗖的某些云服务商要好，很适合做云桌面(阿里云只有一个港区云轻量还算物美价廉其线路还是分忙闲的)。你可以赶在618新购，然后下一个3年用家人的再新购，腾讯函数云网站做成小程序可以接入大量微信用户。。3年1500左右是我的理想投入，因为一台手机3年就刚好报费。视云主机为托管实体机的成本考虑就很容易理解吧。618的onedrive也几乎半价，仅官方版， 要购买互联onedrive参照https://docs.microsoft.com/zh-cn/microsoft-365/admin/services-in-china/buy-or-try-subscriptions?view=o365-21vianet，也是导向去买官方onedrive的网站购买，https://www.microsoft.com/zh-cn/microsoft-365/compare-china-global-versions-microsoft-365，互联只有Microsoft 365商业版，它是 Office 365 的升级版,(单用户43一个月，包年36，由于疫情听说包年有6月免费)没有官方细分的个人版和家庭版,每个用户都是1t加很多附属服务（商业基础只有web office），我们知道，windows是使用域的。世纪互联和windows官方用的是windows的基础设施搭建的onedrive，使用的登录域完全不同,二套产品是分别开发的，api支持和客户端支持情况不一，因此在接下来创建帐号时域名位置就可以区别看到。互联使用的是xxx@xxx.partner.onmschina.cn。这跟去互联官方azure.cn创建帐买通用云资源和主机创建帐号一样的，不要淘宝买互联帐号，那些全是各种公司的域控下分出来的子帐号（虽然单用户有5t的）而且有各种局限有的没有api权限。淘宝没有行货的互联。除了onedrive计划，互联还有https://www.microsoft.com/zh-cn/microsoft-365/sharepoint/compare-sharepoint-plans这个sharepoint专门计划。72一个月云盘无限容量(实际上就是1到 5到25自提)还可以绑定自定义域控，和享有一个网站。 本人使用的是官方office365+阿里轻量，明年转sharepoint+8元一月的cloud ecs得了。 ———— 关注我 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
利用大容量网盘onedrive配合公有云做你的nas及做站
本文关键字：onedrive打造你的网站图床大文件外链床，sync as network，网盘附件床,onemanager http解发 在《免租用云主机将mineportal2做成nas，是个人件也可服务于网站系统》中我们提到将nas和个人网站合一的思路，，在《mineportal – 一个开箱即用的wordpress+owncloud作为存储后端》我们提到用网盘做网站图床甚至all webapp backend storage的思路，在《统一的分布式数据库和文件系统mongodb，及其用于解决aliyun上做站的存储成本方案》我们讲到过在阿里云上省事做站的成本考虑。 毕竟，我们应用软件的方式就是在一台机器上装个app，这种思路已经深入人心了，所以我们希望做站也一样（像安装应用一样简单）。碰巧网站应用的附件床是必不可少的，一个用户体验好的网站需要大流量和高速度，甚至大存储。这跟nas处理存储的方式和环境要求很相似(现在网盘能达到百M局域网速能代替nas)，所以我们希望它与nas和同步管理连接起来。（群晖有一个wordpress plugin）。这样服务端的网站数据也像手机端的照片，PC端的物料文件一样，参与到nas中心文件库的备份与维护工作中去。这样就大为省事省心了。 PS：我们知道，以ecs为基础的建站成本很高。需要强大的带宽，这是个人承担不了的。于是运营商们提出了无服务器建站serveless，，这基本就是以前的弹性扩展，专门化的“网站云，云网站”。即利用oss做静态资源存储和展示，甚至包括cms中的前端静态网站资源，再利用云函数做应用托管，来弥补静态网站动态性不够的问题，所谓函数，也就是相当于一般网站/移动应用的plugin（这些相当wordpress plugin,,etc,,是函数集），它们帮你装好了各种语言backend，也提供了一个类似容器的主机环境，你免去了搭建服务器的工作，这应该也是我storage backend webapp的一种实现，最后利用cdn做分发流量租赁。你租用它们的oss(专门做站的网盘还有小鸟云这些??没用过),cdn,和函数托管能力，（业务逻辑）由你提供，当然你也可以安装他们提供的函数模块。， 但即使这样，其实综合成本上，一套下来也不会低。只是稍为省事。但是如果有了一个函数容器或ecs托管环境再搭配大容量网盘，情况或许就不一样了，网盘的线路是第三方的。不走服务器流量，网盘一般都是cdn加速的且网盘一切都是买断的。相当于为网站服务器准备了一个超大图床，甚至附件线路，sync as network线路,这实际上就是上面提到的更强大的oss替代。网盘如果能作为附件床再好不过，甚至可以当成个人nas用。 我们在前面提到在云上装黑果。本来我们的设想是利用云上osx能利用上icloud的能力，自建icloud且提供一个能运行icloud的托管服务的环境。Icloud是一个非常好的文件异备服务(多端同步防冲突算法非常鲁棒)，icloud是被设计供icloud产品系内部使用的，直接在icloudrive和国内环境下使用icloud速度很快托管在云贵，是一个非常好的小型nas（除了它不支持在线视频等一些局限）。但却不是一个好的附件床。它的外链分享（自2019起支持）是打开一张网页，点其中的按钮下载。目前还没有像oneindex一样的方案将它转成直链（能wget url大文件这种，能通过api展示markdown托管静态资源。）。况且受国内政策影响的,在中国，域名绑定一个国内空间就要备案。免备案的都是走国外路线的。，分享作为外链全部导到香港,速度大打折扣。况且即使能用，icloud的空间也有限，也没有强大的api支持。不支持其它os开发。我甚至用过用icloud pages+外链分享来做站可是不够省事。 Onedrive是另外一个选项，Windows这二年跟云和linux靠得越来越近了。这一切源于在微软工作的印度小哥的决策，onedrive在同步算法和client app支持方面跟icloud没法比，除了价格，（买断制不带onedrive的单office系列要便宜点，只有订阅制的带onedrive 1t/6t的office365系列618，1111，1212，1231去淘宝买或买可以差不多半价200左右得到，它也有国内网络互联运营版的onedrive。也有官方版走国际线路，国内速度肯定好点。价格也便宜点，但国内和官方版接下来提到的api支持可能不一样，购买时看产品描述问清楚）。，另外它还有对webapp和各种语言的api，这样并不局限于是什么托管环境（vps,虚拟主机，腾讯云函数，herku），借此你可以得到存储在它当中的文件直接外链，配合云主机/虚拟机/云函数环境可以将它做成个人nas和网站图床（不知道免费版5g有没有api可用），这样的程序主要是一些php的，有oneindex,olaindex(这个程序是php cli命令行版，还提供基于aria2 cmd实现的云下载功能),等等。前者可做成web界面的网盘。后者可以做成命令版。其它还有onemanager,onelist,pyone,cuteone,sharelist,fodi,cuteonep。 其中onemanger（https://github.com/qkqpttgf/OneManager-php）也是一个php网站程序，较oneindex,olaindex更强大，它也支持互联版。甚至支持安装在云主机和腾讯scf上。下面通过它来讲解试验。 使用云主机： 建好lamp环境，选择宝塔这样的会比较省事，上传https://github.com/qkqpttgf/OneManager-php代码，创好网站。添加onedrive盘，我们选择国际版，自己申请id和机密，会把你转向到这个链接: https://apps.dev.microsoft.com/#/quickstart/graphIO?publicClientSupport=false&appName=OneManager&redirectUrl=https:%2F%2Fscfonedrive.github.io&allowImplicitFlow=false&ru=https:%2F%2Fdeveloper.microsoft.com%2Fzh-cn%2Fgraph%2Fquick-start%3FappID%3D_appId_%26appName%3D_appName_%26redirectUrl%3Dhttps:%2F%2Fscfonedrive.github.io%26platform%3Doption-php 程序提供的转向url中有OneManager&redirectUrl=https://scfonedrive.github.io&platform=option-php这样的一部分参数，可以快速创建，否则需要去https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade手动创建，保存你的应用机密，网页转向，选择php(官方提供一个带php composer的足够环境来支持你的函数)，把注册成功处的应用id也保存下来。以后也可在https://account.live.com/consent/Manage管理你的所有应用。 将客户应用id和机密填入到onemanager处，应用跳转，蹦出一个错，不管，直接进入onemanager url，成功，可以看到用你的域名加文件夹加文件名就可以形成对应文件的直接外链。而你也有一个小nas网盘了（可以上传，也可以下载，可以在线播放，但速度感人，最好是大量小文件，大文件分享获取有些吃力。不过像moeclub用于存镜像，然后港区ecs通过installnet装机不错）。至于如何加密，如何连接多个帐号用完6T(可以把这么多用户想象成oss的buket)。自行研究。 使用腾讯云函数机： 腾讯云函数有一个免费额度的cloudbase套（包月免费自动续费），包括静态网站托管（如果要使用这个，cloudbase应用环境要转成按量，不过也照样享有一定免费额度）和scf，这就是我们上面的云网站，阿里云的弹性扩展一类的东西。 我们使用的是单独作为一个产品的云函数去安装。它会出现在cloudbase免费云函数列表中。去cloudbase中去创一个helloworld云函数扩展，进入https://console.cloud.tencent.com/scf/index会看到被分配到了上海区，下面就在这里安装onemanager。 跟安装在云主机上相比，除了不需要安装环境（云函数受自带language runtime backended），这里的区别，从下面步骤可以看出： 直接选择云函数服务区上海新建，命名空间default，另外一个是你的那个cloudbase云函空间，。我们看到php7.2函数模板里面就有onemanager。尝试选择它直接下一步部署，不进行任何设置直接点完成。 函数管理，解发管理，添加触发方式，选择API网关，勾选集成响应。访问API网关，其它就跟上面一样了。 现在尝试将其复制到cloudbase命名空间，在云函数在函数名列表中看到有个复制，但是无法复制到cloudbase云函空间，提示无法完成。只能在函数代码处先下载为zip包，在cloudbase新命名空间新建php7.2空白函数的函数代码处，删掉默认index.php上传zip包,（直接上传onemanager.git源码zip提示函数不正常，需要修正onemanager.git源码为tcf适用版本为https://github.com/tencentyun/scf-demo-repo/tree/master/Php7.2-SCFonedrive使用再cloudbase命令行上传）。代码中config.json中"memorySize": 改为256，选择http触发，触发路径/onemanager，但是执行失败，看函数日志，Object of class stdClass could not be converted to string in /var/user/function/common.php on line 90,原因不明，看源码像是路径处理错误。还可能是因为cloudbase的云函数只支持http而非上面api网关方式模拟http触发导致（而独立腾讯云函数产品 2019年12月起只支持api模拟http）。 不管了，反正都有免费额度，就使用单独云函数版吧。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
把DI当online packer用:利用installnet制作一个云装机packerpe（2）
本文关键字：自建udeb站镜像。local repository debian installer preseed,Preseed install from local repository,start http server in a preseed file,debian中用NC+SHELL实现的一个web服务,浏览器装机,Preseed failed with exit 2,d-i preseed/early_command string stuck hang,linux grep -o 只匹配字串 继把Debianinstaller当online packer用文章1，本文继续讲解生成packerpe。 给前面的脚本增加和镜像格式判断，统一wget和dd progress 增强主要是为了pipecmdstr处整合，稍后会看到(因此也顺便支持了onelist,oneindex这种网盘外链作为ddurl地址，其实质是302跳转体)。这段替换前文的cd /tmp/boot;到echo -e "Downloading kernel : ${LinuxMirror}/....../debian-installer/amd64/initrd.gz"间的内容： LIBC6_SUPPORT='pool/main/g/glibc/libc6_2.28-10_amd64.deb' declare -A SHARED_SUPPORT SHARED_SUPPORT=( ["webfs1"]="pool/main/g/gnutls28/libgnutls30_3.6.7-4+deb10u3_amd64.deb" ["webfs2"]="pool/main/p/p11-kit/libp11-kit0_0.23.15-2_amd64.deb" ["webfs3"]="pool/main/libt/libtasn1-6/libtasn1-6_4.13-3_amd64.deb" ["webfs4"]="pool/main/n/nettle/libnettle6_3.4.1-1_amd64.deb" ["webfs5"]="pool/main/n/nettle/libhogweed4_3.4.1-1_amd64.deb" ["webfs6"]="pool/main/g/gmp/libgmp10_6.1.2+dfsg-4_amd64.deb" ["webfs7"]="pool/main/libf/libffi/libffi6_3.2.1-9_amd64.deb" ["webfs8"]="pool/main/m/mime-support/mime-support_3.62_all.deb" ["webfs9"]="pool/main/libu/libunistring/libunistring2_0.9.10-1_amd64.deb" ["wgetssl7"]="pool/main/libi/libidn2/libidn2-0_2.0.5-1+deb10u1_amd64.deb" ["wgetssl8"]="pool/main/libp/libpsl/libpsl5_0.20.2-2_amd64.deb" ["wgetssl9"]="pool/main/p/pcre2/libpcre2-8-0_10.32-5_amd64.deb" ["wgetssl10"]="pool/main/u/util-linux/libuuid1_2.33.1-0.1_amd64.deb" ["wgetssl11"]="pool/main/z/zlib/zlib1g_1.2.11.dfsg-1_amd64.deb" ) HTTPD_SUPPORT='pool/main/w/webfs/webfs_1.21+ds1-12_amd64.deb' WGETSSL_SUPPORT='pool/main/w/wget/wget_1.20.1-1.1_amd64.deb' DDPROGRESS_SUPPORT='pool/main/b/busybox/busybox_1.30.1-4_amd64.deb' UNZIP='' DDURL='' [[ -n "$LIBC6_SUPPORT" ]] && { echo -ne 'Add libc6 support(binary-amd64/Package)...' wget --no-check-certificate -qO ${LIBC6_SUPPORT##*/} $LinuxMirror/$LIBC6_SUPPORT; \ ar x ${LIBC6_SUPPORT##*/} data.tar.xz; xz -d data.tar.xz; tar xf data.tar; \ rm -rf data.tar ${LIBC6_SUPPORT##*/} [[ ! -f /tmp/boot/lib/x86_64-linux-gnu/libc.so.6 ]] && echo 'Error! LIBC6_SUPPORT.' && exit 1 || sleep 3s && echo -en "[\033[32mok\033[0m]\n" ; # [[ $? -eq '0' ]] && echo -ne 'Success! \n\n' } [[ -n "$HTTPD_SUPPORT" ]] && { echo -ne 'Add httpd and httpd shared support(binary-amd64/Package)...' wget --no-check-certificate -qO ${HTTPD_SUPPORT##*/} $LinuxMirror/$HTTPD_SUPPORT; \ ar x ${HTTPD_SUPPORT##*/} data.tar.xz; xz -d data.tar.xz; tar xf data.tar; \ rm -rf data.tar ${HTTPD_SUPPORT##*/} for pkg in $(echo "${!SHARED_SUPPORT[@]}" |sed 's/\ /\n/g' |sort -n |grep "^webfs") do CurPkg="${SHARED_SUPPORT[$pkg]}" [ -n "$CurPkg" ] || continue wget --no-check-certificate -qO ${CurPkg##*/} $LinuxMirror/$CurPkg; \ ar x ${CurPkg##*/} data.tar.xz; xz -d data.tar.xz; tar xf data.tar; \ rm -rf data.tar ${CurPkg##*/} done [[ ! -f /tmp/boot/usr/bin/webfsd ]] && echo 'Error! HTTPD_SUPPORT.' && exit 1 || sleep 3s && echo -en "[\033[32mok\033[0m]\n" ; # [[ $? -eq '0' ]] && echo -ne 'Success! \n\n' } if [[ -n "$tmpDDURL" ]]; then echo -ne 'setting final ddurl and prepare unzip mode...' echo "$tmpDDURL" |grep -q '^http://\|^ftp://\|^https://'; [[ $? -ne '0' ]] && echo 'No valid URL in the DD argument,Only support http://, ftp:// and https:// !' && exit 1; IMGHEADER="$(curl -Is "$tmpDDURL")"; IMGTYPE="$(echo "$IMGHEADER" | grep -E -o 'raw|qcow2|gzip|x-gzip|301|302')" || IMGTYPE='0'; # [[ "$IMGTYPE" -ne '0' ]] && echo 'not a raw,tar,gunzip or 301/302 ref file, exit ... !' && exit 1 || { [[ "$IMGTYPE" == 'raw' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]\n"; [[ "$IMGTYPE" == 'qcow2' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]\n"; [[ "$IMGTYPE" == 'gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gzip \033[0m]\n"; [[ "$IMGTYPE" == 'x-gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m x-gzip \033[0m]\n"; [[ "$IMGTYPE" == 'gunzip' ]] && UNZIP='2' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gunzip \033[0m]\n"; [[ "$IMGTYPE" == '302' ]] && IMGHEADERCHECKPASS2="$(echo "$IMGHEADER" |grep 'Location: http'|sed 's/Location: //g')" && IMGHEADERCHECKPASS2=${IMGHEADERCHECKPASS2%$'\r'} && IMGHEADERCHECKPASS3="$(curl -Is "$IMGHEADERCHECKPASS2" |grep 'content-location: http'|sed 's/content-location: //g')" && IMGHEADERCHECKPASS3=${IMGHEADERCHECKPASS3%$'\r'} && IMGTYPECHECKPASS2="$(curl -Is "$IMGHEADERCHECKPASS3" | grep -E -o 'raw|qcow2|gzip|x-gzip|gunzip')" && { [[ "$IMGTYPECHECKPASS2" == 'raw' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]\n"; [[ "$IMGTYPECHECKPASS2" == 'qcow2' ]] && UNZIP='0' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m raw \033[0m]\n"; [[ "$IMGTYPECHECKPASS2" == 'gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gzip \033[0m]\n"; [[ "$IMGTYPECHECKPASS2" == 'x-gzip' ]] && UNZIP='1' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m x-gzip \033[0m]\n"; [[ "$IMGTYPECHECKPASS2" == 'gunzip' ]] && UNZIP='2' && DDURL="$tmpDDURL" && sleep 3s && echo -en "[\033[32m gunzip \033[0m]\n"; } [[ "$IMGTYPE" == '0' ]] && echo 'not a raw,tar,gunzip or 301/302 ref file, exit ... !' && exit 1; # } else echo 'Please input vaild image URL! '; exit 1; fi #echo "$DDURL" |grep -q '^https://' #[[ $? -eq '0' ]] && { [[ -n "$WGETSSL_SUPPORT" ]] && { echo -ne 'always Add wgetssl and wgetssl support(binary-amd64/Package)...' wget --no-check-certificate -qO ${WGETSSL_SUPPORT##*/} $LinuxMirror/$WGETSSL_SUPPORT; \ ar x ${WGETSSL_SUPPORT##*/} data.tar.xz; xz -d data.tar.xz; tar xf data.tar; \ rm -rf data.tar ${WGETSSL_SUPPORT##*/}; mv -f /tmp/boot/usr/bin/wget /tmp/boot/usr/bin/wget2 for pkg in $(echo "${!SHARED_SUPPORT[@]}" |sed 's/\ /\n/g' |sort -n |grep "^wgetssl") do CurPkg="${SHARED_SUPPORT[$pkg]}" [ -n "$CurPkg" ] || continue wget --no-check-certificate -qO ${CurPkg##*/} $LinuxMirror/$CurPkg; \ ar x ${CurPkg##*/} data.tar.xz; xz -d data.tar.xz; tar xf data.tar; \ rm -rf data.tar ${CurPkg##*/} done [[ ! -f /tmp/boot/usr/bin/wget2 ]] && echo 'Error! WGETSSL_SUPPORT.' && exit 1 || sleep 3s && echo -en "[\033[32mok\033[0m]\n" ; # sed -i 's/wget\ -qO-/\/usr\/bin\/wget2\ --no-check-certificate\ --retry-connrefused\ --tries=7\ --continue\ -qO-/g' /tmp/boot/preseed.cfg # [[ $? -eq '0' ]] && echo -ne 'Success! \n\n' } # || { # echo -ne 'Not wgetssl support package! \n\n'; # exit 1; # } #} [[ -n "$DDPROGRESS_SUPPORT" ]] && { echo -ne 'Add ddprogress support(binary-amd64/Package)...' wget --no-check-certificate -qO ${DDPROGRESS_SUPPORT##*/} $LinuxMirror/$DDPROGRESS_SUPPORT; \ ar x ${DDPROGRESS_SUPPORT##*/} data.tar.xz; xz -d data.tar.xz; tar xf data.tar; \ rm -rf data.tar ${DDPROGRESS_SUPPORT##*/} [[ ! -f /tmp/boot/bin/busybox ]] && echo 'Error! DDPROGRESS_SUPPORT.' && exit 1 || sleep 3s && echo -en "[\033[32mok\033[0m]\n" ; # [[ $? -eq '0' ]] && echo -ne 'Success! \n\n' } 如果你发现启动不了文件系统出现制作文件系统时出现的那些错误，那就是可能glibc低了。注意到dd status progress我并未在接下的preseed中用到。 整合精简几大件,the net, the loader, the preseed file 下面是脚本的继续,准备net设置，grub loader和preseed file供打包： sleep 5s echo -e "\n\033[36m# Preparing others\033[0m\n" echo -e "the net" setNet='0' interface='' [ -n "$ipAddr" ] && [ -n "$ipMask" ] && [ -n "$ipGate" ] && setNet='1'; [[ -n "$tmpWORD" ]] && myPASSWORD="$(openssl passwd -1 "$tmpWORD")"; [[ -z "$myPASSWORD" ]] && myPASSWORD='$1$4BJZaD0A$y1QykUnJ6mXprENfwpseH0'; if [[ -n "$interface" ]]; then IFETH="$interface" else IFETH="auto" fi [[ "$setNet" == '1' ]] && { IPv4="$ipAddr"; MASK="$ipMask"; GATE="$ipGate"; } || { DEFAULTNET="$(ip route show |grep -o 'default via [0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.*' |head -n1 |sed 's/proto.*\|onlink.*//g' |awk '{print $NF}')"; [[ -n "$DEFAULTNET" ]] && IPSUB="$(ip addr |grep ''${DEFAULTNET}'' |grep 'global' |grep 'brd' |head -n1 |grep -o '[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}/[0-9]\{1,2\}')"; IPv4="$(echo -n "$IPSUB" |cut -d'/' -f1)"; NETSUB="$(echo -n "$IPSUB" |grep -o '/[0-9]\{1,2\}')"; GATE="$(ip route show |grep -o 'default via [0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}' |head -n1 |grep -o '[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}')"; [[ -n "$NETSUB" ]] && MASK="$(echo -n '128.0.0.0/1,192.0.0.0/2,224.0.0.0/3,240.0.0.0/4,248.0.0.0/5,252.0.0.0/6,254.0.0.0/7,255.0.0.0/8,255.128.0.0/9,255.192.0.0/10,255.224.0.0/11,255.240.0.0/12,255.248.0.0/13,255.252.0.0/14,255.254.0.0/15,255.255.0.0/16,255.255.128.0/17,255.255.192.0/18,255.255.224.0/19,255.255.240.0/20,255.255.248.0/21,255.255.252.0/22,255.255.254.0/23,255.255.255.0/24,255.255.255.128/25,255.255.255.192/26,255.255.255.224/27,255.255.255.240/28,255.255.255.248/29,255.255.255.252/30,255.255.255.254/31,255.255.255.255/32' |grep -o '[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}'${NETSUB}'' |cut -d'/' -f1)"; } [[ -n "$GATE" ]] && [[ -n "$MASK" ]] && [[ -n "$IPv4" ]] || { echo "Not found \`ip command\`, It will use \`route command\`." ipNum() { local IFS='.'; read ip1 ip2 ip3 ip4 <<<"$1"; echo $((ip1*(1<<24)+ip2*(1<<16)+ip3*(1<<8)+ip4)); } SelectMax(){ ii=0; for IPITEM in `route -n |awk -v OUT=$1 '{print $OUT}' |grep '[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}'` do NumTMP="$(ipNum $IPITEM)"; eval "arrayNum[$ii]='$NumTMP,$IPITEM'"; ii=$[$ii+1]; done echo ${arrayNum[@]} |sed 's/\s/\n/g' |sort -n -k 1 -t ',' |tail -n1 |cut -d',' -f2; } [[ -z $IPv4 ]] && IPv4="$(ifconfig |grep 'Bcast' |head -n1 |grep -o '[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}.[0-9]\{1,3\}' |head -n1)"; [[ -z $GATE ]] && GATE="$(SelectMax 2)"; [[ -z $MASK ]] && MASK="$(SelectMax 3)"; [[ -n "$GATE" ]] && [[ -n "$MASK" ]] && [[ -n "$IPv4" ]] || { echo "Error! Not configure network. "; exit 1; } } [[ "$setNet" != '1' ]] && [[ -f '/etc/network/interfaces' ]] && { [[ -z "$(sed -n '/iface.*inet static/p' /etc/network/interfaces)" ]] && AutoNet='1' || AutoNet='0'; [[ -d /etc/network/interfaces.d ]] && { ICFGN="$(find /etc/network/interfaces.d -name '*.cfg' |wc -l)" || ICFGN='0'; [[ "$ICFGN" -ne '0' ]] && { for NetCFG in `ls -1 /etc/network/interfaces.d/*.cfg` do [[ -z "$(cat $NetCFG | sed -n '/iface.*inet static/p')" ]] && AutoNet='1' || AutoNet='0'; [[ "$AutoNet" -eq '0' ]] && break; done } } } [[ "$setNet" != '1' ]] && [[ -d '/etc/sysconfig/network-scripts' ]] && { ICFGN="$(find /etc/sysconfig/network-scripts -name 'ifcfg-*' |grep -v 'lo'|wc -l)" || ICFGN='0'; [[ "$ICFGN" -ne '0' ]] && { for NetCFG in `ls -1 /etc/sysconfig/network-scripts/ifcfg-* |grep -v 'lo$' |grep -v ':[0-9]\{1,\}'` do [[ -n "$(cat $NetCFG | sed -n '/BOOTPROTO.*[dD][hH][cC][pP]/p')" ]] && AutoNet='1' || { AutoNet='0' && . $NetCFG; [[ -n $NETMASK ]] && MASK="$NETMASK"; [[ -n $GATEWAY ]] && GATE="$GATEWAY"; } [[ "$AutoNet" -eq '0' ]] && break; done } } echo -e "the loader" LoaderMode='0' setInterfaceName='0' setIPv6='0' if [[ "$LoaderMode" == "0" ]]; then [[ -f '/boot/grub/grub.cfg' ]] && GRUBVER='0' && GRUBDIR='/boot/grub' && GRUBFILE='grub.cfg'; [[ -z "$GRUBDIR" ]] && [[ -f '/boot/grub2/grub.cfg' ]] && GRUBVER='0' && GRUBDIR='/boot/grub2' && GRUBFILE='grub.cfg'; [[ -z "$GRUBDIR" ]] && [[ -f '/boot/grub/grub.conf' ]] && GRUBVER='1' && GRUBDIR='/boot/grub' && GRUBFILE='grub.conf'; [ -z "$GRUBDIR" -o -z "$GRUBFILE" ] && echo -ne "Error! \nNot Found grub.\n" && exit 1; else tmpINSTANTWITHOUTVNC='0' fi if [[ "$LoaderMode" == "0" ]]; then [[ ! -f $GRUBDIR/$GRUBFILE ]] && echo "Error! Not Found $GRUBFILE. " && exit 1; [[ ! -f $GRUBDIR/$GRUBFILE.old ]] && [[ -f $GRUBDIR/$GRUBFILE.bak ]] && mv -f $GRUBDIR/$GRUBFILE.bak $GRUBDIR/$GRUBFILE.old; mv -f $GRUBDIR/$GRUBFILE $GRUBDIR/$GRUBFILE.bak; [[ -f $GRUBDIR/$GRUBFILE.old ]] && cat $GRUBDIR/$GRUBFILE.old >$GRUBDIR/$GRUBFILE || cat $GRUBDIR/$GRUBFILE.bak >$GRUBDIR/$GRUBFILE; else GRUBVER='2' fi [[ "$GRUBVER" == '0' ]] && { READGRUB='/tmp/grub.read' cat $GRUBDIR/$GRUBFILE |sed -n '1h;1!H;$g;s/\n/%%%%%%%/g;$p' |grep -om 1 'menuentry\ [^{]*{[^}]*}%%%%%%%' |sed 's/%%%%%%%/\n/g' >$READGRUB LoadNum="$(cat $READGRUB |grep -c 'menuentry ')" if [[ "$LoadNum" -eq '1' ]]; then cat $READGRUB |sed '/^$/d' >/tmp/grub.new; elif [[ "$LoadNum" -gt '1' ]]; then CFG0="$(awk '/menuentry /{print NR}' $READGRUB|head -n 1)"; CFG2="$(awk '/menuentry /{print NR}' $READGRUB|head -n 2 |tail -n 1)"; CFG1=""; for tmpCFG in `awk '/}/{print NR}' $READGRUB` do [ "$tmpCFG" -gt "$CFG0" -a "$tmpCFG" -lt "$CFG2" ] && CFG1="$tmpCFG"; done [[ -z "$CFG1" ]] && { echo "Error! read $GRUBFILE. "; exit 1; } sed -n "$CFG0,$CFG1"p $READGRUB >/tmp/grub.new; [[ -f /tmp/grub.new ]] && [[ "$(grep -c '{' /tmp/grub.new)" -eq "$(grep -c '}' /tmp/grub.new)" ]] || { echo -ne "\033[31mError! \033[0mNot configure $GRUBFILE. \n"; exit 1; } fi [ ! -f /tmp/grub.new ] && echo "Error! $GRUBFILE. " && exit 1; sed -i "/menuentry.*/c\menuentry\ \'Packer PE \[debian\ jessie\ amd64\]\'\ --class debian\ --class\ gnu-linux\ --class\ gnu\ --class\ os\ \{" /tmp/grub.new sed -i "/echo.*Loading/d" /tmp/grub.new; INSERTGRUB="$(awk '/menuentry /{print NR}' $GRUBDIR/$GRUBFILE|head -n 1)" } [[ "$GRUBVER" == '1' ]] && { CFG0="$(awk '/title[\ ]|title[\t]/{print NR}' $GRUBDIR/$GRUBFILE|head -n 1)"; CFG1="$(awk '/title[\ ]|title[\t]/{print NR}' $GRUBDIR/$GRUBFILE|head -n 2 |tail -n 1)"; [[ -n $CFG0 ]] && [ -z $CFG1 -o $CFG1 == $CFG0 ] && sed -n "$CFG0,$"p $GRUBDIR/$GRUBFILE >/tmp/grub.new; [[ -n $CFG0 ]] && [ -z $CFG1 -o $CFG1 != $CFG0 ] && sed -n "$CFG0,$[$CFG1-1]"p $GRUBDIR/$GRUBFILE >/tmp/grub.new; [[ ! -f /tmp/grub.new ]] && echo "Error! configure append $GRUBFILE. " && exit 1; sed -i "/title.*/c\title\ \'DebianNetboot \[jessie\ amd64\]\'" /tmp/grub.new; sed -i '/^#/d' /tmp/grub.new; INSERTGRUB="$(awk '/title[\ ]|title[\t]/{print NR}' $GRUBDIR/$GRUBFILE|head -n 1)" } if [[ "$LoaderMode" == "0" ]]; then [[ -n "$(grep 'linux.*/\|kernel.*/' /tmp/grub.new |awk '{print $2}' |tail -n 1 |grep '^/boot/')" ]] && Type='InBoot' || Type='NoBoot'; LinuxKernel="$(grep 'linux.*/\|kernel.*/' /tmp/grub.new |awk '{print $1}' |head -n 1)"; [[ -z "$LinuxKernel" ]] && echo "Error! read grub config! " && exit 1; LinuxIMG="$(grep 'initrd.*/' /tmp/grub.new |awk '{print $1}' |tail -n 1)"; [ -z "$LinuxIMG" ] && sed -i "/$LinuxKernel.*\//a\\\tinitrd\ \/" /tmp/grub.new && LinuxIMG='initrd'; if [[ "$setInterfaceName" == "1" ]]; then Add_OPTION="net.ifnames=0 biosdevname=0"; else Add_OPTION=""; fi if [[ "$setIPv6" == "1" ]]; then Add_OPTION="$Add_OPTION ipv6.disable=1"; fi BOOT_OPTION="auto=true $Add_OPTION hostname=debian domain= -- quiet" [[ "$Type" == 'InBoot' ]] && { sed -i "/$LinuxKernel.*\//c\\\t$LinuxKernel\\t\/boot\/vmlinuz $BOOT_OPTION" /tmp/grub.new; sed -i "/$LinuxIMG.*\//c\\\t$LinuxIMG\\t\/boot\/initrd.img" /tmp/grub.new; } [[ "$Type" == 'NoBoot' ]] && { sed -i "/$LinuxKernel.*\//c\\\t$LinuxKernel\\t\/vmlinuz $BOOT_OPTION" /tmp/grub.new; sed -i "/$LinuxIMG.*\//c\\\t$LinuxIMG\\t\/initrd.img" /tmp/grub.new; } sed -i '$a\\n' /tmp/grub.new; fi [[ "$tmpINSTANTWITHOUTVNC" == '0' ]] && { GRUBPATCH='0'; if [[ "$LoaderMode" == "0" ]]; then [ -f '/etc/network/interfaces' -o -d '/etc/sysconfig/network-scripts' ] || { echo "Error, Not found interfaces config."; exit 1; } sed -i ''${INSERTGRUB}'i\\n' $GRUBDIR/$GRUBFILE; sed -i ''${INSERTGRUB}'r /tmp/grub.new' $GRUBDIR/$GRUBFILE; [[ -f $GRUBDIR/grubenv ]] && sed -i 's/saved_entry/#saved_entry/g' $GRUBDIR/grubenv; fi cd /tmp/boot; COMPTYPE="gzip"; CompDected='0' for ListCOMP in `echo -en 'gzip\nlzma\nxz'` do if [[ "$COMPTYPE" == "$ListCOMP" ]]; then CompDected='1' if [[ "$COMPTYPE" == 'gzip' ]]; then NewIMG="initrd.img.gz" else NewIMG="initrd.img.$COMPTYPE" fi mv -f "/boot/initrd.img" "/tmp/$NewIMG" break; fi done [[ "$CompDected" != '1' ]] && echo "Detect compressed type not support." && exit 1; [[ "$COMPTYPE" == 'lzma' ]] && UNCOMP='xz --format=lzma --decompress'; [[ "$COMPTYPE" == 'xz' ]] && UNCOMP='xz --decompress'; [[ "$COMPTYPE" == 'gzip' ]] && UNCOMP='gzip -d'; $UNCOMP < /tmp/$NewIMG | cpio --extract --verbose --make-directories --no-absolute-filenames >>/dev/null 2>&1 echo -e "the preseed" [[ "$UNZIP" == '0' ]] && PIPECMDSTR='wget2 --no-check-certificate -qO- '$DDURL' |dd of=$(list-devices disk |head -n1)'; [[ "$UNZIP" == '1' ]] && PIPECMDSTR='wget2 --no-check-certificate -qO- '$DDURL' |tar zOx |dd of=$(list-devices disk |head -n1)'; [[ "$UNZIP" == '2' ]] && PIPECMDSTR='wget2 --no-check-certificate -qO- '$DDURL' |gzip -dc |dd of=$(list-devices disk |head -n1)'; cat >/tmp/boot/preseed.cfg<<EOF d-i preseed/early_command string anna-install d-i debian-installer/locale string en_US d-i console-setup/layoutcode string us d-i keyboard-configuration/xkb-keymap string us d-i hw-detect/load_firmware boolean true d-i netcfg/choose_interface select $IFETH d-i netcfg/disable_autoconfig boolean true d-i netcfg/dhcp_failed note d-i netcfg/dhcp_options select Configure network manually # d-i netcfg/get_ipaddress string $ipAddr d-i netcfg/get_ipaddress string $IPv4 d-i netcfg/get_netmask string $MASK d-i netcfg/get_gateway string $GATE d-i netcfg/get_nameservers string 8.8.8.8 d-i netcfg/no_default_route boolean true d-i netcfg/confirm_static boolean true d-i mirror/country string manual #d-i mirror/http/hostname string $IPv4 d-i mirror/http/hostname string httpredir.debian.org d-i mirror/http/directory string /debian d-i mirror/http/proxy string # webfsd -i $IPv4 -p 80 -r /var/log/ -l /var/log/httpd.log d-i apt-setup/services-select multiselect d-i debian-installer/allow_unauthenticated boolean true d-i passwd/root-login boolean ture d-i passwd/make-user boolean false d-i passwd/root-password-crypted password $myPASSWORD d-i user-setup/allow-password-weak boolean true d-i user-setup/encrypt-home boolean false d-i clock-setup/utc boolean true d-i time/zone string US/Eastern d-i clock-setup/ntp boolean true d-i partman/early_command string $PIPECMDSTR; /sbin/reboot EOF [[ "$LoaderMode" != "0" ]] && AutoNet='1' [[ "$setNet" == '0' ]] && [[ "$AutoNet" == '1' ]] && { sed -i '/netcfg\/disable_autoconfig/d' /tmp/boot/preseed.cfg sed -i '/netcfg\/dhcp_options/d' /tmp/boot/preseed.cfg sed -i '/netcfg\/get_.*/d' /tmp/boot/preseed.cfg sed -i '/netcfg\/confirm_static/d' /tmp/boot/preseed.cfg } #[[ "$GRUBPATCH" == '1' ]] && { # sed -i 's/^d-i\ grub-installer\/bootdev\ string\ default//g' /tmp/boot/preseed.cfg #} #[[ "$GRUBPATCH" == '0' ]] && { # sed -i 's/debconf-set\ grub-installer\/bootdev.*\"\;//g' /tmp/boot/preseed.cfg #} sed -i '/user-setup\/allow-password-weak/d' /tmp/boot/preseed.cfg sed -i '/user-setup\/encrypt-home/d' /tmp/boot/preseed.cfg #sed -i '/pkgsel\/update-policy/d' /tmp/boot/preseed.cfg #sed -i 's/umount\ \/media.*true\;\ //g' /tmp/boot/preseed.cfg [[ -f '/boot/firmware.cpio.gz' ]] && { gzip -d < /boot/firmware.cpio.gz | cpio --extract --verbose --make-directories --no-absolute-filenames >>/dev/null 2>&1 } 注意上面的脚本中输出至preseed file至EOF止的内容必须顶格写，Ks.cf是installment.sh用来用同样ubuntu支持preseed支持centos的方法。已删，在文件中，我注释了原来使用内置的webfsd服务器作镜像的方案，因为preseed early command string中欠入webfsd启动命令（放anna install前），会导致PE启动时early command运行时，umount时前台却在加载webfsd卡住，需要ctrlc才能继续，但实际上webfsd已成功运行。 所以我将注释webfsd的逻辑放在preseed中某位置，这个位置是它应该启动时的时机。实际上early command string中都不比它合适。未来想办法让它以正确方式起作用。 打包 sleep 5s echo -e "\n\033[36m# Packaging \033[0m\n" find . | cpio -H newc --create --quiet | gzip -9 > /boot/initrd.img; [[ "$tmpINSTANTWITHOUTVNC" == '0' ]] && echo "finished, auto reboot after 30s...(if needed, you can press ctrl c to interrupt to bak the /boot/initrd.img, then manually reboot to continue)";sleep 30s rm -rf /tmp/boot; } [[ "$tmpINSTANTWITHOUTVNC" == '1' ]] && { sed -i '$i\\n' $GRUBDIR/$GRUBFILE sed -i '$r /tmp/grub.new' $GRUBDIR/$GRUBFILE echo -e "\n\033[33m\033[04mIt will reboot! \nPlease connect VNC! \nSelect\033[0m\033[32m Packer PE [debian jessie amd64] \033[33m\033[4mto install system.\033[04m\n\n\033[31m\033[04mThere is some information for you.\nDO NOT CLOSE THE WINDOW! \033[0m\n" echo -e "\033[35mIPv4\t\tNETMASK\t\tGATEWAY\033[0m" echo -e "\033[36m\033[04m$IPv4\033[0m\t\033[36m\033[04m$MASK\033[0m\t\033[36m\033[04m$GATE\033[0m\n\n" read -n 1 -p "Press Enter to reboot..." INP [[ "$INP" != '' ]] && echo -ne '\b \n\n'; } chown root:root $GRUBDIR/$GRUBFILE chmod 444 $GRUBDIR/$GRUBFILE if [[ "$LoaderMode" == "0" ]]; then sleep 3 && reboot >/dev/null 2>&1 else rm -rf "$HOME/loader" mkdir -p "$HOME/loader" cp -rf "/boot/initrd.img" "$HOME/loader/initrd.img" cp -rf "/boot/vmlinuz" "$HOME/loader/vmlinuz" [[ -f "/boot/initrd.img" ]] && rm -rf "/boot/initrd.img" [[ -f "/boot/vmlinuz" ]] && rm -rf "/boot/vmlinuz" echo && ls -AR1 "$HOME/loader" fi 脚本结束。 —— 这个脚本还有其它很多需要增强的地方，比如dd progress显示。还比如改成了生成双分区。保留packerpe到第一分区。整盘其实可以preseed/partman成二个分区，一个分区200M放生成的packerpe自身（未来，还可以在这个packerpe集成dbcolinux或集成linuxbpot,coreboot，clover等）， 还比如，扩展镜像到整个磁盘空间，实际上windows通过ntfs fuse是实现了的。对于linux磁盘，要处理镜像分区表适配到目标整个磁盘。这不光适用于dd方案。也适用于将磁盘打包成dd镜像（脚本中改变pipecmdstr，镜像扩容缩容）。然后nc 监听，供其它机器下载其镜像或直接dd。这是这个脚本的反向功能。 还比如，利用webfsd的cgi改dd地址。也可用grub的auto url变换dd地址。Ddurl参数保留到下一次。且读取位置不再在preseed中。 但是我不想做了，以后继续吧。这些天做windows server 2019 core的dd镜像也较累了，用了跟做osx云镜像差不多的方法：在linuxkvm中套虚拟机。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
利用citrix xenapp and xendesktop建立你的云桌面
本文关键字：云办公。真正可用的个人云桌面,云下载云播放。GPO dns，xendeskop storeweb无法完成您的请求 其实云电脑桌面，虚拟桌面vdi,瘦客户端这样的东西出现很久了，只是它们从来没有像今天的疫情时代一样让人对他们更为关注。一般来说谈到云电脑人们都会想到最初的vps，正如谈到云桌面这个人们会想到远程桌面这个工具层面的东西一样，但其实云桌面与办公，可以是内涵和外延很广的东西，比如虚拟化这些东西结合起来，造就了一些专门做vdi的公司，如vmware,pd,citrix，（citrix很早就提出了BYOD，带着你的设备办公的理念。它的xenapp and xendesktop产品就是vdi产品，当然citrix不止这个产品，它还有虚拟化全套，和workspace云工作台这样的东西-类似钉钉,slack）同类产品是vmware的view。。越来越多的云服务商开通了它们的云桌面，云手机产品。，，还有很多。 只是云电脑用于生产力和异地办公，甚至发展普及到个人使用代替实体电脑的程度，需要解决很多问题。相信谁都尝试过用一般的云主机和一般的远程桌面办公，用云电脑，性能和速度，成本，都是大问题。gd5446显卡的云机在远程桌面下打开有flash的网页，鼠标寸步难移，对于多媒体应用，有点接近云游戏的实现难度了，可是我们知道，现在这个时代，5G才刚刚开始，云游戏还没有被普及。 citrix，是如何尽可能在现有条件下克服问题的，又达到什么样的成果？citrix中的app,xdesktop，使用一种ica的协议。这种协议可以工作在恶劣的带宽环境中，极大利用带宽，而且可以实时多媒体（类似云游戏的那种）,可以打视频电话等，体验接近普通本地办公电脑，简直可以类比虚拟机界中的pd(pd的远程桌面也做的不错可以发布remote app)，云存界的icloud+icloudriver(其算法十分稳健体验好。比如删除中同步，单用户范围内秒传)。 反正我是怀疑这效果，所以我看了下阿里云的云桌面产品，阿里的云桌面称为图形工作台，按量测试，先开通集群，然后开通实例，只在杭州h区i区有机器，系统是windows 10 2019srv based on ltsc，最低2h2g的机器，看看显卡驱动,是qemu -vga std虚拟出来的机器，当然也有用vgpu显卡的。硬盘也是virtue scsi，非blk（我的装黑果文章中，用这种显卡会更兼容，装黑果失败了所以我来折腾citrix windows了），集群和实例都收费，集群更贵阿0.71元一个小时。先看效果。带宽给足的情况下，效果居然还可以，播放高清视频和本地差不了多少，也没有出现开flash网页鼠标飘飘的情况！可做小型云下载云播放系统。 这部分费用产生在哪？，citrix是一个分布式结构，讲究扩展和性能，部署在多机环境，基本大量使用windows的基础设施来构建自身（比如用windows的身份机制，用windows的iis，用windows的数据库，需要配合windows域控，iis,selserver一起工作，很吃内存），一般使用多台windows server来构建服务器集群（也有linux版的Citrix），服务器有二大件：desktop delivery controller（DDC，其中又分几个小件，其中有Delivery controller业务核心,Licensing Server认证服务器,studio,storefront这二配置工具,citrix director组件。）和virtual delivery agent（VDA），virtual delivery agent就是安装在按量机中的程序，服务器的主要部分delivery controller是安装在阿里云别的服务器上的 ，感情阿里云是在这里建立了各种delivery controller服务器，与citrix授权一起产生租费的（citrix收费的方式是订阅制），然后通过某台阿里云称为gws的域服务器（暂且这么命名吧）作认证透出服务，我们可在网卡dns处找到它172.16.0.2xx， 现在我们来考虑自建所有的服务器自测效果，如果自己建的也能达到差不多的效果，证明citrix是高度可用的,citrix的授权有30天的免费期可以拿来测试。我重新开了2台港区按量2H4G装的win2019 datacenter with ui，港区网络有时好有时坏，方便长时间看综合效果，， 1台2C4G测试机上安装通用服务器（域控，mssqlserver）和ddc业务服务器并配置，相当于gws 这部分服务器程序在新装机器上，包括os在内约占2G多启动内存,随着运行会占更大内存。因此需要一个4G左右的机器。且Delivery controller是（业务核心）组件，生产环境按接入的用户数，基本上4G为起步。如果内存不够且是ssd机，手动加大虚存尝试。我开的4G。 先处理下服务器，，计算机名修改为ddc，表示这里安装的是通用windows servers程序和ddc服务器。方便辨认，计算机名也有讲究，licensing server用它跟citrix注册，因为这台测试机器要作为许可服务器在内的服务器，许可的主机会使用主机名向ctirix注册。本机如果有域先脱域(系统属性，计算机名修改处，从当前域转为WORKSPACE工作组，这样就脱域了)，注意，如果ping localhost得到结果是你的windows用ipv6 ::1表示域名，那么添加REG_DWORD值16进制，HKLMSYSTEMCurrentControlSetServicesTcpip6ParametersDisabledComponents，设置成20，重启这样ipv4就好了。dns为自动获取。 把官方按量机中的用户目录/下载中的二个文件citrix_virtual_apps_and Desktops_7_1912.iso和citrixcqi.msi复制过来（citrix专属驱动就复制不过来了）。其内就是主要的服务端安装文件了(也有客户端receiver for Windows and osx，在客户端,我们要使用到的就是其workspace app中的->receiver中的->viewer,注意到receiver 和delivery 是一对相反词)。打开iso，从iso复制出来安装文件夹到桌面，安装期间几次要重启计算机再继续，如果直接使用iso安装会失去挂载。 ———PS：如果你这台机器性能不够，其实你可以在这里仅安装dc，而把licensing server,studio,和storefront。甚至域控，都放在域内另外一台机安装，或者把许可服务作为通用服务放到域内另外一台机中去，为了达到动态组装，扩展，性能，这也是生产环境中推荐的方式,ddc不能在一台域控上安装只能在一台域成员上安装，除非你先装DDC再装域控，因为安装程序的逻辑是：当它发现本机有域控，就不能安装Delivery controller 和virtual delivery agent。至于mssql，它是可以跟域控一起装的，我们这里也是这样做的，虽然install sqlserver on a domain controller is not recommended。我们的测试是域控,mssql,ddc全装在这台机。——— 执行autoinstall，安装DDC，组件统统选上除了Director（在安装程序的逻辑中，以上都可以部分安装，directer可选安装,），选上sqlserver，安装程序建议5g，要开的端口会提示你许可证服务器7279,27000,80828083,Dc:80,89,443,Storefront:80 443，统统在服务端防火墙处放行，最后发送珍断信息不要勾选，因为你是在本地用户下安装，非域下，安装完窗口末尾有一行提示”本机需要域才能配置DDC”。ddc安装完后，如果需要新添组件，可以通过programfiles/XendesktopServersetup/xendesktopserversetup.exe修改，需要保留安装程序文件夹。 现在安装域控，windows域控相当于osx server的部署描述符文件，服务器管理中添加角色和功能，,基于角色或基于功能的安装，选择ad目录域服务,接下来功能就不用选了，勾“如果需要，重新启动服务器。”部署后黄色叹号处需要配置，将此服务器提升为域控制器，添加新林，域名填ctx.srv。表示，这是一个citrix用处的srv的集群，这是域的内网根域名（整体很容易理解：这是一个命名为ddc，以ctx域林为根，自身为控域的域成员，使用的内网dns逻辑是xxx.xxx.srv，避免使用com那些结尾的域名，如果有人注册了这个com，就会登录到它的服务器，所以这里还是不用com的好），域名系统服务器全局编录，林功能级别保持为server 2016，netbios域名默认CTX。无法创建dns委派，略过，会自动重启，本地adminstrator会变成域用户主机会变成ddc.ctx.srv，下次登录不到本地administrator,只能用域逻辑登录。因为是域控，不可能再作为本地机器登录了。ctx/administrator自动也是本地管理员组。设置domain policy，让域内主机自动配置。比如如果你想让域内主机都不用按ctlaltdel登录，需要在计算机管理，组策略中找到域，default domain policy,计算机配置，策略，windows设置，安全设置，本地策略，安全选项，交互式登录，由没有定义改成已启用。 ————Ps:我们手动设置下mssqlserver，以免配置时等待过长。让sqlserver工作在域上使用ctx/administrator logon，默认安装方式下给你的logon帐号是nt认证built in network service,网络是tcpip enable, tcp all使用动态端口。这种方式下等待过长。 事实上mssql不推荐安装在域控上，如果你要接入另外的域机器上的mssql，需要那台机器上的实例选择了“混合模式”验证身份登陆，这样才可以顺利的进行接下来的远程连接。。Services account用CTX/administrator,密码填上。auto startup type。安装完后，开始菜单打开SQL Server configure manager, network configure, 找到实例for sqlexpress的protocols,tcpip enable,给于所有ip，enable,yes,端口1443，特别注意ipall也要1433,同样在这个窗口，去SQL Server services那里右击restart一下，windows防火墙里放行。打开防火墙→高级设置→入站规则→新建规则→选择C:Program FilesMicrosoft SQL ServerMSSQL14.MSSQLSERVERMSSQLBinnsqlserver.exe，如果你的防火墙关的，不用去理这步。———— 现在来配置，使ddc和vdc运行起来。现在开始在studio中配置（如果登录的不是域用户无法继续），打开studio，交付应用程序和桌面，创建站点的交付控制器开始，，使用30天免费订阅(也可以在这里选择授权文件安装，也可在localhost8082处进行，这时，主机名就会影响往citrix注册)，选择空配置，并输入站点名称default，studio,storefront等要用到sqlserver信息，如果是连接外部域主机，三个位置都填”mssql域主机名,1433“，提示没有权限，使用同域的ctxadministrator继续,连接，正在生成数据库架构。正在创建storefront群集,完成。如果你使用内存有限的机器，配置服务阶段会卡很久。 第一个站点建好了。可以在内网直接用浏览器加html5查看，但无法连接远程桌面，因为站点中没有远程桌面或app定义，在storeservice可以看到http://ddc.ctx.srv/Citrix/StoreWeb/,,这称为receiver for web站点。进去但是里面是没有任何程序的。配置成公网访问，会在iis管理器default site处添加一个https443段在http段下，进去storeweb一样是空的(实际上添加一个citrix gateway)。我们来安装vda(同样会产生一个有定义的Citrix gateway). 再添加一个domain用户，为接下来加入域的vda计算机用，active directory用户和计算机处，找到ctx.srv,computers，添加minlearn@ctx.srv，不能改密码永不过期，默认就是domain users组。 第二台2C4G测试机上安装配置vda,桌面服务器，用客户端连接，运行 这次安装DC本身，如果你是同一个镜像恢复过来的系统，要去windows/system32/sysprep/下执行sysprep.exe。进入系统全新体验oobe确定重新生成一个sid.这部分仅是一个代理占内存不大。但却是桌面应用所在的地方。当然性能也是越高越好，仅上网使用浏览器的话2G吧。 ————ps:Ddc不推荐与vda所在服务器整合，我们的测试也采用分开机制，Delivery controller中的Delivery controller组件是桌面分发的上层服务器，VDA是桌面分发的下层服务器，这个也算服务器，只要receiver才是最终客户端。生产环境中这二者往往装在不同机器上。citrix本身就是面向licensing to 500+ 机器起步的，况且不好直接拿服务端让人家远程进来吧？况且如果你把ddc,vda安装到一台机去了。登录StoreFront后，会显示“无法完成您的请求”———— dns设为前面win主机的内网ip，准备加入域ctx.srv。系统属性计算名中，先给这台机器主机名叫vda,表示这是vda所在服务器，将这个机器由组切换加入域，重启用第一个服务器上的ctxminlearn用户登录，，整个机器域名会变成vda.ctx.srv，因为这不是域控服务器本地administrator会保留，minlearn用户在本地权限是受限制的,在域用户下，访问设置会出现没有权限或找不到，无法访问本地设备等情形，这要针对找到那个资源或设置条目，执行，通过开始菜单中的windows管理工具找，不要直接开始，设置。改dns，要控制面板，网络和internet，网络连接，解决这种问题需要在域控处一一设置权限。但是我们在本地提升它为管理员也可以，注销切换到本地administrator,在administrator下，本地计算机用户组管理，把ctx/minlearn升为本地administrator组，要先保证dns为域ip哦。 把安装文件拷过来，一样的方式安装VDA,receiver也要安装，因为我们呆会要本地测试一下，启用与服务器的中转连接，组件全不选，功能选一定选上实时音频，防火墙规则都是自动80,1494,2598,8008,1494udp,2598udp,16500-16509udp，，期间会提示远程桌面模式尚未配置（跟其它服务器一样，vda也包装了windows的会话主机当服务器使用），还有119天过期，略过，过程中需要注册到DDC，填ddc.ctx.srv，安装，发送珍断信息不要勾选。后期可以通过programfiles/Xendesktopvdasetup/xendesktopvdasetup.exe修改vda向ddc注册的参数。驱动管理器中发现新装了很多citrix相关的虚拟设备和驱动，主要是io设备。 ————PS：DDC与VDA也有一个高可用模式，允许recevier直接与ddc通讯：虚拟桌面的代理VDA默认是与DDC之间每5分钟通信一次的啦，所以如果DDC都挂了情况下，VDA和DDC之间的通信就会出现问题。如果 XenDesktop 站点中的所有 Delivery Controller 均出现故障，可以将 Virtual Delivery Agent (VDA)配置为在高可用性模式下运行，以便用户可以继续访问和使用他们的桌面。 在高可用性模式下，VDA 将接受来自用户的直接 ICA 连接，而不是由控制器代理的连接。这样就可以做到在DDC都挂了情况下依然继续使用虚拟桌面喔。就这是VDA的高可用模式。不过我没有测试高可用模式。———— 继续返回第一台机配置。Studio中创建计算机目录，多会话操作系统，未进行计算机管理的计算机，其它服务或技术，添加计算机，计算机目录是安装了vda的计算机的目录,这里填vda.ctx.srv，添加一个交付组，帐号使用ctxminlearn。 再次访问https://你的公网ip/Citrix/StoreWeb/发现有内容了，点击会引导你下载windows activex控件，或workspace客户端(其实我们只是使用workspace中的view来远程桌面，真正的workspace是一个工作流聚合程序)。我们的目标是使用客户端连接而不仅是浏览器。打开workspace，添加服务器地址，账户为域内minlearn。 成功！效果嘛，暂时看还是可以的。。 ——— 我后来用2台1h2g的轻量代替上面的测试方案，1台代替方案中的1-dc，studio,storefront(也即，仅保留ddc中的许可),1台代替方案中的2+studio,storefront(把除许可外的其它ddc部件移到这)。把非核心和核心服务器分开，做一个个人最低费用的且可用的vdi 集群（二台1h2g港轻量68元/月，三年是接近2000,其实我理想中的终端价格应该是>500-800元/一年，因为一般手机电脑3年就坏了，3年投入1000-2000是我的心理价位。云主机虽然不是终端还有云带宽，但价格下完全可以拿来类比）可是第二台机应该2h4g才好用。 Studio用来连接ddc,配置完后可以删掉？需要改动时再次连接就是。 也尝试过上面扩展中的2,3做成按需，和尝试过把按需ecs打造成关机0收费无盘网启系统节省费用，但最终证明这个是做不到的。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
把DI当online packer用:利用installnet制作一个云装机packerpe（1）
本文关键字：pebuilder,云主机装机就用云镜像装机。直接在网络上组装生成目标系统，模拟群晖的webassit,wget --spider to stdout not work 前面《利用hashicorp packer把dbcolinux导出为虚拟机和docker格式》系列中我们讲到了packer，这是一个类虚拟机管理器的工具，它有一个iso模式，允许用户提供一个最原始的iso和一系列脚本。，然后在这个系统上运行脚本内命令行，完成格式硬盘，安装软件包，动态生成目标系统镜像内容。关机即得这个镜像。packer也常被用来在本地生成虚拟机镜像，然后上传导入到云主机供云主机用，然而，这有一个缺点，生成镜像通常很大，本地网络拉取一些特定区的镜像速度也不太好，最后，还得上传，那么，有没有一种在云主机上类packer，边拉取软件边生成目标镜像的工具呢？如果有，是否适用所有系统呢，比如windows不提供linux方式的kernel与rootfs分离，也不支持软件包仓库丰富系统，是不是也同样适用这个过程呢？ —————Ps:debianinstaller，是一种debian netboot system组成的类packer的环境，当可引导安装介质(安装光盘，安装U盘)启动后，可以选择进入文本向导模式或图形向导模式，然后完成如下操作 加载 kernel，initrd，加载额外的Udeb包,完成安装界面初始化环境; 如果启动参数包含preseed文件，则会按照preseed文件内定义的规则自动执行,如果没有对应的规则,则返回交互界面; 交互界面会引导用户完成键盘，时区，主机名，网络，用户密码，分区等设置，存储在当前安全器环境中; 完成分区格式化等操作后，该磁盘会被挂载到 /target，安装器会调用debootstrap在 /target 完成核心系统的构建; 安装器通过执行 chroot 操作进入以 /target 为根的系统中，完成软件源的更新，执行 tasksel，弹出可选软件菜单; 安装可选的软件包, 完成上述操作后,最后配置 grub, 将之前保存的全部设置应用，完成安装过程. ————— 可见，整个debian installer 类似packer，只不过这里bootstrap系统是debian（packer iso模式下的iso）。工具是Debian-installer等，脚本是preseed,provision过程是运行这个pe回放preseed。当被用于云主机时，使用debian installerb也可在其中完成识别硬盘格式化等操作，，实际上它开始是一个按preseed自动化的livecd，先启动进livecd，还原回放preseed时，可以在这里继续安装完整系统（preseed）完成即得到目标镜像，debian-installer不光用来生成debian派生系的镜像，对于windows,osx这种没有在线组装能力的系统而言，可直接在preseed早期就通过wget,tar,dd的管理道dd镜像完成安装目标系统 ——— 格盘，装系统，这其实是一种比服务商提代的镜像恢复方式和dd方式更符合云机装机的原生方式。《云主机上装windows iso》《virtio 0pe》这是我早期使用virtiope网络装机的文章，我们讲到过pebuilder，我们还谈到过群晖的webassit都是类比物，在后面一些文章，尤其是《云主机上装黑群，黑果》系列中我们都提到过moeclue的installnet.sh脚本，用它网络装机可在线完成。就相当pebuilder ，生成的pe相当packer ， 下面来完善这个脚本 注意！！！！！！！！：使用此脚本安装镜像默认会抹除你硬盘中的所有内容。请谨慎尝试。注意！！！！！！！！：使用此脚本安装镜像默认会抹除你硬盘中的所有内容。请谨慎尝试。注意！！！！！！！！：使用此脚本安装镜像默认会抹除你硬盘中的所有内容。请谨慎尝试。 前置 主要是把selectmirror精简为dd only，把一些全局变量置为局部过程变量，不用作为参数喂给脚本。 #!/bin/bash ## License: GPL,Written By MoeClub.org,moded by minlearn for dd purpose only export tmpDDURL='' export tmpMIRROR='' export tmpINSTANTWITHOUTVNC='0' export ipAddr='' export ipMask='' export ipGate='' export UNKNOWHW='0' export UNVER='6.4' while [[ $# -ge 1 ]]; do case $1 in -dd|--ddurl) shift tmpDDURL="$1" shift ;; --mirror) shift tmpMIRROR="$1" shift ;; -i|--instantwithoutvnc) shift tmpINSTANTWITHOUTVNC="$1" shift ;; --ip-addr) shift ipAddr="$1" shift ;; --ip-mask) shift ipMask="$1" shift ;; --ip-gate) shift ipGate="$1" shift ;; *) if [[ "$1" != 'error' ]]; then echo -ne "\nInvaild option: '$1'\n\n"; fi echo -ne " Usage(args are self explained):\n\tbash $(basename $0)\t-dd/--ddurl\n\t\t\t\t--mirror\n\t\t\t\t-i/--instantwithoutvnc\n\t\t\t\t--ip-addr/--ip-gate/--ip-mask\n\t\t\t\t\n" exit 1; ;; esac done [[ "$EUID" -ne '0' ]] && echo "Error:This script must be run as root!" && exit 1; function CheckDependence(){ FullDependence='0'; for BIN_DEP in `echo "$1" |sed 's/,/\n/g'` do if [[ -n "$BIN_DEP" ]]; then Founded='0'; for BIN_PATH in `echo "$PATH" |sed 's/:/\n/g'` do ls $BIN_PATH/$BIN_DEP >/dev/null 2>&1; if [ $? == '0' ]; then Founded='1'; break; fi done if [ "$Founded" == '1' ]; then echo -en "$BIN_DEP"; else FullDependence='1'; echo -en "[\033[31mNot Install\033[0m]"; fi echo -en "\t\t\t[\033[32mok\033[0m]\n"; fi done if [ "$FullDependence" == '1' ]; then echo -ne "\n\033[31mError! \033[0mPlease use '\033[33mapt-get\033[0m' or '\033[33myum\033[0m' install it.\n\n\n" exit 1; fi } clear && echo -e "\n\n\n\n\n\n\n\n\n\n\033[36m# Check Dependence\033[0m\n" CheckDependence wget,ar,awk,grep,sed,cut,cat,cpio,curl,gzip,find,dirname,basename; function SelectMirror(){ [ $# -ge 1 ] || exit 1 AddonMirror=$(echo "$1" |sed 's/\ //g') declare -A MirrorBackup MirrorBackup=(["Debian0"]="" ["Debian1"]="http://httpredir.debian.org/debian") echo "$AddonMirror" |grep -q '^http://\|^https://\|^ftp://' && MirrorBackup[{"Debian"}0]="$AddonMirror" for mirror in $(echo "${!MirrorBackup[@]}" |sed 's/\ /\n/g' |sort -n |grep "^Debian") do CurMirror="${MirrorBackup[$mirror]}" [ -n "$CurMirror" ] || continue CheckPass1='0'; DistsList="$(wget --no-check-certificate -qO- "$CurMirror/dists/" |grep -o 'href=.*/"' |cut -d'"' -f2 |sed '/-\|old\|Debian\|experimental\|stable\|test\|sid\|devel/d' |grep '^[^/]' |sed -n '1h;1!H;$g;s/\n//g;s/\//\;/g;$p')"; for DIST in `echo "$DistsList" |sed 's/;/\n/g'` do [[ "$DIST" == "jessie" ]] && CheckPass1='1' && break; done [[ "$CheckPass1" == '0' ]] && { echo -ne '\njessie not find in $CurMirror/dists/, Please check it! \n\n' bash $0 error; exit 1; } CheckPass2=0 ImageFile="SUB_MIRROR/dists/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz" [ -n "$ImageFile" ] || exit 1 URL=`echo "$ImageFile" |sed "s#SUB_MIRROR#${CurMirror}#g"` wget --no-check-certificate --spider --timeout=3 -o /dev/null "$URL" [ $? -eq 0 ] && CheckPass2=1 && echo "$CurMirror" && break done [[ $CheckPass2 == 0 ]] && { echo -ne "\033[31mError! \033[0minitrd.gz not find in $CurMirror/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/! \n"; bash $0 error; exit 1; } } sleep 5s echo -e "\n\n\033[36m# Select Mirror\033[0m\n" LinuxMirror=$(SelectMirror "$tmpMIRROR") echo -e "${LinuxMirror}" 缓存udebs和kernel,rootfs: 把udebs仓库也缓存下来放进pe，做成本地镜像。因为rootfs中有一个httpd，可以通过preseed启动，做成仓库镜像服务器。可以看到preseed中地址用了127.0.0.1，验证也去掉了By default the installer requires that repositories be authenticated using a known gpg key. This setting can be used to disable that authentication,a udeb就是一个方便在liveos中运行的简化的deb。 sleep 5s echo -e "\n\033[36m# All prerequisites Done,Begin processing [DD URL:$tmpDDURL,Instant without vnc:$tmpINSTANTWITHOUTVNC]\033[0m\n" [[ -d /tmp/boot ]] && rm -rf /tmp/boot; mkdir -p /tmp/boot/usr/bin; cd /tmp/boot; LIBC6_SUPPORT='pool/main/g/glibc/libc6_2.19-18+deb8u10_amd64.deb' WGETSSL_SUPPORT='' declare -A HTTPD_SUPPORT HTTPD_SUPPORT=( ["webfs1"]="pool/main/w/webfs/webfs_1.21+ds1-10_amd64.deb" ["webfs2"]="pool/main/g/gnutls28/libgnutls-deb0-28_3.3.8-6+deb8u7_amd64.deb" ["webfs3"]="pool/main/p/p11-kit/libp11-kit0_0.20.7-1_amd64.deb" ["webfs4"]="pool/main/libt/libtasn1-6/libtasn1-6_4.2-3+deb8u3_amd64.deb" ["webfs5"]="pool/main/n/nettle/libnettle4_2.7.1-5+deb8u2_amd64.deb" ["webfs6"]="pool/main/n/nettle/libhogweed2_2.7.1-5+deb8u2_amd64.deb" ["webfs7"]="pool/main/g/gmp/libgmp10_6.0.0+dfsg-6_amd64.deb" ["webfs8"]="pool/main/libf/libffi/libffi6_3.1-2+deb8u1_amd64.deb" ["webfs9"]="pool/main/m/mime-support/mime-support_3.58_all.deb" ) DDPROGRESS_SUPPORT='' UNZIP='' [[ -n "$LIBC6_SUPPORT" ]] && { echo -ne 'Add libc6 support(binary-amd64/Package)...' wget --no-check-certificate -qO ${LIBC6_SUPPORT##*/} $LinuxMirror/$LIBC6_SUPPORT; \ ar x ${LIBC6_SUPPORT##*/} data.tar.gz; tar xzf data.tar.gz; \ rm -rf data.tar.gz ${LIBC6_SUPPORT##*/} [[ ! -f /tmp/boot/lib/x86_64-linux-gnu/libc.so.6 ]] && echo 'Error! LIBC6_SUPPORT.' && exit 1 || sleep 3s && echo -en "[\033[32mok\033[0m]\n" ; # [[ $? -eq '0' ]] && echo -ne 'Success! \n\n' } if [[ -n "$tmpDDURL" ]]; then echo "$tmpDDURL" |grep -q '^http://\|^ftp://\|^https://'; [[ $? -ne '0' ]] && echo 'No valid URL in the DD argument,Only support http://, ftp:// and https:// !' && exit 1; curl -Is "$tmpDDURL" | grep -q 'gzip'; [[ $? -ne '0' ]] && echo 'not tar or gunzip file !' && exit 1 || UNZIP='0'; else echo 'Please input vaild image URL! '; exit 1; fi echo "$tmpDDURL" |grep -q '^https://' [[ $? -eq '0' ]] && { [[ -n "$WGETSSL_SUPPORT" ]] && { echo -ne 'Add ssl support(binary-amd64/Package)...' wget --no-check-certificate -qO- $LinuxMirror/$WGETSSL_SUPPORT |tar -x mv -f /tmp/boot/usr/bin/wget /tmp/boot/usr/bin/ [[ ! -f /tmp/boot/usr/bin/wget2 ]] && echo 'Error! WGETSSL_SUPPORT.' && exit 1 || sleep 3s && echo -en "[\033[32mok\033[0m]\n" ; # sed -i 's/wget\ -qO-/\/usr\/bin\/wget2\ --no-check-certificate\ --retry-connrefused\ --tries=7\ --continue\ -qO-/g' /tmp/boot/preseed.cfg # [[ $? -eq '0' ]] && echo -ne 'Success! \n\n' } # || { # echo -ne 'Not ssl support package! \n\n'; # exit 1; # } } #[[ -n "$HTTPD_SUPPORT" ]] && { echo -ne 'Add httpd support(webfs binary-amd64 Package)...' for pkg in $(echo "${!HTTPD_SUPPORT[@]}" |sed 's/\ /\n/g' |sort -n |grep "^webfs") do CurPkg="${HTTPD_SUPPORT[$pkg]}" [ -n "$CurPkg" ] || continue wget --no-check-certificate -qO ${CurPkg##*/} $LinuxMirror/$CurPkg; \ ar x ${CurPkg##*/} data.tar.xz; xz -d data.tar.xz; tar xf data.tar; \ rm -rf data.tar ${CurPkg##*/} done [[ ! -f /tmp/boot/usr/bin/webfsd ]] && echo 'Error! HTTPD_SUPPORT.' && exit 1 || sleep 3s && echo -en "[\033[32mok\033[0m]\n" ; # [[ $? -eq '0' ]] && echo -ne 'Success! \n\n' #} echo -e "Downloading kernel : ${LinuxMirror}/....../debian-installer/amd64/initrd.gz" IncFirmware='0' wget --no-check-certificate -qO '/boot/initrd.img' "${LinuxMirror}/dists/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz" [[ $? -ne '0' ]] && echo -ne "\033[31mError! \033[0mDownload 'initrd.img' for \033[33mdebian\033[0m failed! \n" && exit 1 wget --no-check-certificate -qO '/boot/vmlinuz' "${LinuxMirror}/dists/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux" [[ $? -ne '0' ]] && echo -ne "\033[31mError! \033[0mDownload 'vmlinuz' for \033[33mdebian\033[0m failed! \n" && exit 1 MirrorHost="$(echo "$LinuxMirror" |awk -F'://|/' '{print $2}')"; MirrorFolder="$(echo "$LinuxMirror" |awk -F''${MirrorHost}'' '{print $2}')"; if [[ "$IncFirmware" == '1' ]]; then wget --no-check-certificate -qO '/boot/firmware.cpio.gz' "http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/jessie/current/firmware.cpio.gz" [[ $? -ne '0' ]] && echo -ne "\033[31mError! \033[0mDownload 'firmware' for \033[33mdebian\033[0m failed! \n" && exit 1 fi vKernel_udeb=$(wget --no-check-certificate -qO- "http://jessieMirror/dists/$DIST/main/installer-amd64/current/images/udeb.list" |grep '^acpi-modules' |head -n1 |grep -o '[0-9]\{1,2\}.[0-9]\{1,2\}.[0-9]\{1,2\}-[0-9]\{1,2\}' |head -n1) [[ -z "vKernel_udeb" ]] && vKernel_udeb="3.16.0-6" echo -e "Downloading debs : ${LinuxMirror}/pool/....." IncUdebrepo='1' if [[ "$IncUdebrepo" == '1' ]]; then mkdir -p /tmp/boot/var/log/debian; udeburl=".*pool\/main\(.*\)udeb.*" wget --no-check-certificate -qO- "$LinuxMirror/dists/jessie/main/debian-installer/binary-amd64/Packages.gz" |gunzip -dc|sed "/$udeburl/!d"|sed "s/Filename: //g"|while read line do path=${line%/*} mkdir -p /tmp/boot/var/log/debian/$path file=${line##*/} wget --no-check-certificate -qO /tmp/boot/var/log/debian/$path/$file $LinuxMirror/$line done mkdir -p /tmp/boot/var/log/debian/dists/jessie/main/binary-amd64/ mkdir -p /tmp/boot/var/log/debian/dists/jessie/main/debian-installer/binary-amd64/ mkdir -p /tmp/boot/var/log/debian/dists/jessie/main/installer-amd64/current/images/ wget --no-check-certificate -qO /tmp/boot/var/log/debian/dists/jessie/Release $LinuxMirror/dists/jessie/Release wget --no-check-certificate -qO /tmp/boot/var/log/debian/dists/jessie/main/binary-amd64/Release $LinuxMirror/dists/jessie/main/binary-amd64/Release wget --no-check-certificate -qO /tmp/boot/var/log/debian/dists/jessie/main/debian-installer/binary-amd64/Release $LinuxMirror/dists/jessie/main/debian-installer/binary-amd64/Release,同路径下还有一个Packages.gz wget --no-check-certificate -qO /tmp/boot/var/log/debian/dists/jessie/main/installer-amd64/current/images/udeb.list $LinuxMirror/dists/jessie/main/installer-amd64/current/images/udeb.list chmod -R 0644 /tmp/boot/var/log/debian/ fi ———— 脚本版权归原作者所有。还可以像群晖web assit一样,https://wiki.debian.org/DebianInstaller/WebInstaller。preseed还可用于网络和qemu启动 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践(9)：继续处理云主机上黑果clover preboot问题
本文关键字：clover fake display，unbound variable python_command, manual build compiling Clover from source,EDK2_REV,mac Merge lines between two patterns using sed, gnu sed vs bsd sed，sed同时匹配多个模式1管道符方式2多e选项3分号连接4大括号一次执行,sed同时匹配多个模式异与或模式，sed模式空间匹配多个模式循环内欠结构模式空间 在前面，我们确定了一切重新开始从clover突破的思路，由于能驱动mojave的最低是4514+，因此，我们最终希望得到一个4514+ 云机上能过preboot阶段的clover(vs chameleon，clover分开了bootstrape和firmware，其核心部件不是boot6,boot7而是cloverx64.efi，clover的boot是已编译好的就在源码包里无须编译得到且不常变，得到编译结果后，我们只须保持boot和前面文章中的镜像文件中的大部分不变，替换cloverx64.efi就可以测试)，能从souceforge clover project files栏直接下载到的clover版本是断续的，实测过preboot的版本是3799其下一个版本3811开始的稍高版本在轻量云机上就报type x64 0D通用保护错误。而且，上述能下载到的二进制版本，其说明文件或执行结果中(clover about menu)除了自身并没有关于任何其它源码组件，比如edk2的rev号，而edk2是clover的一个大件，所以这给我们判断异常发生在那层对应关系的哪个部件中带来了麻烦 ，比如我们无法判断下载到的3799可能并没有使用其发布日最新的edk2,type x64 0d是否主要由cloverx64中的edk2源码部分导致而来。—— (尽管如此，我们在其论坛中https://www.insanelymac.com/forum/topic/304530-clover-change-explanations/发现了一些信息，比如，Rev 3264 Compatibility with new EDK2 18475 (and more?).Rev 3338 Compatibility with recent EDK2, because of changes in Autogen.py build tool.Rev 3471 ，It is now possible to build Clover with -xcode5 using versions of Xcode prior to 7.3 - as long as DevicePathToText.c is patched from Patches_for_EDK2.Rev 3952 New patch_for_edk2 rev 23215+ preventing load efi drivers and applications.With this patch we can use recent EDK2 at least 23447.)。Rev 4331 : 使用25687，REV 4496 : Synchronized Patches_for_EDK2 with r27233,Rev 5068 : Clover at sourceforge is synced to EDK2 tagged as edk2-stable201908 https://github.com/CloverHackyColor/edk2/archive/edk2-stable201908.zip，Rev 5104 Clover switched to C++ programming language PS：edk2与ovmf与clover的关系。EDK, EDK II是intel关于uefi实现:tianocore的一个开源实现。clover是作为edk2的一个子组件存在编译出来的，clover用它作虚拟uefi界面与引导osx的主要工作。OVMF "is a project to enable UEFI support for Virtual Machines，面向虚拟机的。clover就是使用它的。BIOS/CSM,EFI,UEFI,现在的UEFI就是它的升级版本，即：tianocore->edk2->ovmf（UEFI对qemu的实现）->clover。clover中有一个rEFIt_UEFI，应该是clover引导osx的中心模块，而edk2是用来提供firmware的中心模块。 clover也是一个十几年的项目了，早期clover的编译默认同步当时最新的edk2，后期clover edk2对应已经时间上脱节很多了。且都移到了github了，只能凭有上述insanelymac上clover change explanations上记载的来确定版本对应关系。最终我们要得到一个接近前文用的5070左右过preboot的编译结果，且修正上述不保留revs对应的版本，只能像当初处理chameleon一样，从源码级编译出一个能在云机上克服preboot就出问题的版本，我们只能亲自动手，手动控制这二个rev关系，从编译中寻求答案。 准备工作 早期clover的编译http://clover-wiki.zetam.org/Development已挂掉，其步骤是把对应版本的cloverefiboot-code-rxxxx改名为Clover放到edk2源码根中，然后在这二套源码中交替运行脚本，先编译全局性的toolchain,mtoc,nasm,gettext,extras等，然后update clover下的 patchs到edk2根，最后在clover下运行编译脚本，带动edk2下的编译脚本。实际结果cloverx64.efi生成在edk2/build/具体toolchain命名的文件夹结果中(我们并不需要全套clover，直到make pkg)。以上这是流程，工具链方面，Currently, 01.02.2016 it is possible to compile full Clover package only with gcc-4.9.Since April 2016 the best compilation is possible with XCODE5 toolset, so no more gcc-4.x needed.Tested on Xcode 4.4.1 and Xcode 7.3.1，Gcc49 toolchain被设定在linux上运行和osx下都可运行，但osx下默认Xcode，我们也使用Xcode。—— 而且我们不使用其它的第三方的整合编译方案build command（micky968,cloveglow,etc..）直接用源码包的。这样方便我们从0开始学习，下面开始： 我们先准备好虚拟机环境，文章1，文章4装的是10.11.4，10.12，文章7用了10.13，由于clover推荐xcode731,这里我们使用10.11.6搭配xcode7.3.1（注意非command tools），从10.11.6开始苹果安装包好像加了厚厚的验证，系统内部也加了sip，往PD中安装时很麻烦，跟文章7一样，果断关PD host网设好时间，一切重新开始，不过100%的时候卡了好久我强制重启，进入系统（如果你还碰到没有符合资源的软件包，安装时需要登录icloud之类，果断一切重来），但是我在10.11.6上安装xcode7.3.1失败，提示Xcode[45010]: DVTDownloadable: Failed to preflight installation Error Domain=PKInstallErrorDomain Code=102 "The package “MobileDeviceDevelopment.pkg” is untrusted." 又是时间问题，把控制面板中自动设置时间去掉，在客户机断网(使用服务使其不活跃)，Edit and set the date of your Mac as Jan 1st, 2016.或者设置pd客户机与主机时间不同步统统上，最后完成安装xcode。在mac下sudo 拷贝和删除文件时提醒Operation not permitted，无法显示隐藏文件，。是因为Max OS X El 中增加了rootless功能， 即sudo也不能操作部分文件目录， 利用configuration window -> Hardware -> Boot Order，boot into OS X Recovery Mode on Parallels Desktop,Enable Select boot device on startup，重启进入发现这也是一个虚拟EFI之类的东西，csrutil disable即可。 前面测出3811就报异常了，于是这里先从如下3810，22803源码组合开始，从https://sourceforge.net/p/cloverefiboot/code/3800/tarball?path=以及http://sourceforge.net/projects/edk2/22803/tarball?path=）下载源码包。解压到一个文件夹内。使用如下脚本先预处理脚本,这个updatesrcforonce.sh脚本放在下载解压后的edk2 src和clover src组成的文件夹并列的位置，修改下面开头的二个rev号，执行它，正确的结果是没有任何回显，不能多次执行，多次执行破坏源码重新解压并update即可，我都是在host OS X 10.15上执行然后将处理过后源码放进pd osx10.11.6编译：： #下面脚本工作在大约rev 4000之前的脚本 export cloverrev=r3811 export edkrev=r22803 #(处理ebuild,保存revs完善源码缺失) export reporev="repoRev\=\"0000" export newreporev="repoRev\=\"$cloverrev,$edkrev" sudo sed -i "" "s/$reporev/$newreporev/g" cloverefiboot-code-$cloverrev/ebuild.sh # (处理ebuild,默认使用Xcode，即不使用toolchain仅nasm,与下面的toolchain gcc49二选一) export nasmprefix='echo[[:space:]]*\"NASM_PREFIX' export newnasmprefix='export NASM_PREFIX\=\~\/src\/opt\/local\/bin\/ \&\& echo \"NASM_PREFIX' sudo sed -i "" "s/$nasmprefix/$newnasmprefix/g" cloverefiboot-code-$cloverrev/ebuild.sh # (处理ebuild,替换toolchain为gcc49) #export toolchaindir='\"\$CLOVERROOT\"\/..\/..\/toolchain' #export newtoolchaindir='\~\/src\/opt\/local' #sudo sed -i "" "s/$toolchaindir/$newtoolchaindir/g" cloverefiboot-code-$cloverrev/ebuild.sh #（处理ebuild,替换edk2dir） export edk2dir="cd[[:space:]]*\"\$CLOVERROOT\"\/.." export newedk2dir="cd \"\$CLOVERROOT\"\/..\/edk2-code-$edkrev-trunk\/" sudo sed -i "" "s/$edk2dir/$newedk2dir/g" cloverefiboot-code-$cloverrev/ebuild.sh #(处理ebuild,替换platformfile) export platformfile='Clover\/Clover.dsc' export newplatformfile='\$\{CLOVERROOT\}\/Clover.dsc' sudo sed -i "" "s/$platformfile/$newplatformfile/g" cloverefiboot-code-$cloverrev/ebuild.sh #(替换patchs引用为edk2根，因为将来要update.sh) export patchesdir='Clover\/Patches_for_EDK2\/' sudo sed -i "" "s/$patchesdir//g" {cloverefiboot-code-$cloverrev/Clover.dsc,cloverefiboot-code-$cloverrev/Clover.fdf} #(替换FLASH_DEFINITION) export cloverfdffile="Clover\/Clover.fdf" export newcloverfdffile="..\/cloverefiboot-code-$cloverrev\/Clover.fdf" sudo sed -i "" "s/$cloverfdffile/$newcloverfdffile/g" cloverefiboot-code-$cloverrev/Clover.dsc #(替换剩下的Clover\路径引用) cloverrest="Clover\/" newcloverrest="..\/cloverefiboot-code-$cloverrev\/" sudo sed -i "" "s/$cloverrest/$newcloverrest/g" {cloverefiboot-code-$cloverrev/Clover.dsc,cloverefiboot-code-$cloverrev/Clover.fdf} #替换.inf,(下面命令无回显，要验证结果 需要 grep -rl "被替换的字符串" *，如果没有结果了,说明替换成功了，后来执行时如果build.py... : error xxx tbuild error，也是这里没替换成功，好好检查) export cloverpkgfile="Clover\/CloverPkg" export newcloverpkgfile="..\/cloverefiboot-code-$cloverrev\/CloverPkg" export grubfsdir="Clover\/GrubFS" export newgrubfsdir="..\/cloverefiboot-code-$cloverrev\/GrubFS" export fsinjectdir='Clover\/FSInject' export newfsinjectdir="..\/cloverefiboot-code-$cloverrev\/FSInject" sudo find . -name "*.inf"|xargs grep -rl "Clover/CloverPkg"|xargs sed -i "" "s/$cloverpkgfile/$newcloverpkgfile/g" sudo find . -name "*.inf"|xargs grep -rl "Clover/GrubFS"|xargs sed -i "" "s/$grubfsdir/$newgrubfsdir/g" sudo find . -name "*.inf"|xargs grep -rl "Clover/FSInject"|xargs sed -i "" "s/$fsinjectdir/$newfsinjectdir/g" #替换.inf(for高级一点的版本) export grubfsdir2="Clover\/FileSystems\/GrubFS" export newgrubfsdir2="..\/cloverefiboot-code-$cloverrev\/FileSystems\/GrubFS" sudo find . -name "*.inf"|xargs grep -rl "Clover/FileSystems/GrubFS"|xargs sed -i "" "s/$grubfsdir2/$newgrubfsdir2/g" #修改-Werror(出错时使用) #export werror='-Werror[[:space:]]*' #sudo grep -rl "\-Werror" *|xargs sed -i "" "s/$werror//g" sudo mv edk2-code-$edkrev-trunk/edk2/* edk2-code-$edkrev-trunk/ sudo rm -rf edk2-code-$edkrev-trunk/edk2 #如果手动在Finder中替换，要选择合并而不是替换。 sudo cp -R -f cloverefiboot-code-$cloverrev/Patches_for_EDK2/* edk2-code-$edkrev-trunk/ sudo rm -rf cloverefiboot-code-$cloverrev/Patches_for_EDK2 新建一个download放到与二个src root和update.sh并列，(离线下载好nasm-2.12.02.tar.bz2，修改buildnasm中的export DIR_DOWNLOADS=${DIR_DOWNLOADS:-$MAIN_TOOLS/download}为export DIR_DOWNLOADS=${DIR_DOWNLOADS:-$PWD/download}，在PD osx10.11.6中编译出nasm。 最好clover src下ebuild.sh，如下这几行注释掉：# Bash options set -e # errexit set -u # Blow on unbound variable(不去掉，高版本edk2会出现unbound variable python_command),下面就可以开始了。 编译测试一个直到rev 5068不报异常的cloverx64.efi 在PD osx10.11.6中cd到src root/clover src root，sudo rm -rf /usr/local/bin/mtoc,mtoc.NEW，sudo ./ebuild.sh cleanall sudo ebuild.sh(-mc不要了，因为我们的测试环境中cdboot就是-mc的,-mc是使用boot7，相当于ebuild.sh -h出来的-D USE_BIOS_BLOCKIO=1，默认没使用-gcc49，默认Xcode5，第一次执行不用执行cleanall，实际这个cleanall是个鸡肋，不要用) ebuild.sh这是一个企图涵盖linux/osx的脚本，在linux和osx下都可编译使用gcc49 toolchain，(-h查看其参数，也存在一个对最终结果的配置过程)，执行后，clover源码作为一个组件被转到edk2编译过程，在那里会Initializing workspace，根据Clover src root/Clover.dsc(ebuild.sh默认-p Clover.dsc)定义的配置文件转到edk2 srcroot/build/Conf开始编译，最后生成结果cloverx.efi或clover64.efi到edk2 srcroot/build/toolchain named dir下: 如果出现tbuild执行错误就是上面准备工作的脚本没成功替换或重复替换了且preboot通过(通过tcpe上传cloverx64.efi到云机，测试,一般一个版本测试三次，因为有时能preboot的都偶尔会异常，跟chamleon尿性一样，这时直接重启服务器,冷启而不是从tcpe中reboot热启)， 3810 2016-10-14，edk 22803,通过编译和preboot，3811 2016-10-14，edk 22803，通过编译和preboot，利用半分思路测试，成功时大胆跨100，1000个rev，不成功时跟据最近一个成功视版本跨度取一半继续测试：3900，2016-11-02, edk 23078，没编译通过，提示 implicit declaration of function 'ARRAY_SIZE' is invalid in C99，看编译出错提示，在对应的文件中，把#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) 加进去(从22943开始)，编译通过，preboot也通过,4000 2017-02-06,23837，2.4k第一个版本,异常,3950 2016-12-01,23452，异常,3925 2016-11-17，23297，异常,3915 2016-11-09,23212，异常,3910 2016-11-07,23098，异常,3905 23091，异常 分析3901-3905，23079-23091异常，考虑主要是edk2 rev的变化导致的，现在用3901 23079-23091来测试,23088通过。23089通过。23090 通过,直到23091有了下面的变化。https://sourceforge.net/p/edk2/code/23091/log/?path=：by edk2buildsystem:MdePkg/BaseMemoryLib*: check for zero length in ZeroMem ()Unlike other string functions in this library, ZeroMem () does notreturn early when the length of the input buffer is 0. So add thesame to ZeroMem () as well, for all implementations of BaseMemoryLibliving under MdePkg/This fixes an issue with the ARM implementation of BaseMemoryLibOPtDxe,whose InternalMemZeroMem code does not expect a length of 0, and alwayswrites at least a single byte. 按上面的log，revert changes since edk r23091即可。我们发现3901-3906,23091可以通过preboot了，本地虚拟机也可。 继续从clover开始,往前几个版本又不行了，又黑屏了3906 2016-11-07,23098 通过,但是preboot会重启3907 2016-11-07,23098 ,23098 编译未通过,提示error: use of undeclared identifier 'CHAR_NULL’,，从这个版本23089更改了CHAR_NULL的定义位置。把提示找不到符号的源码加进去如下： #define CHAR_NULL 0x0000 #define CHAR_BACKSPACE 0x0008 #define CHAR_TAB 0x0009 #define CHAR_LINEFEED 0x000A #define CHAR_CARRIAGE_RETURN 0x000D 编译通过，preboot不通过异常。这次是Commit [r3907] https://sourceforge.net/p/cloverefiboot/code/3907/log/?path= :update CPU definitions by ErmaC,这个commit提到的rEFIt_UEFI/Platform/下几个源码文件里有很多cpu model变化，我们记得变色龙的修正路子也是类似。要revert changes since clover r3907，把Platform.h中的define CPU_MODEL_SKYLAKE_S先删掉，然后把接下来一行CPU_MODEL_SKYLAKE_D改为CPU_MODEL_SKYLAKE_S，其它三文件StateGenerator.c,cpu.c,platformdata.c删除CPU_MODEL_SKYLAKE_D删除所有跟CPU_MODEL_SKYLAKE_D有关的orphaned case skylaked逻辑块。 5068是最接近我们上文5070的，现在直接来尝试编译5068+https://github.com/CloverHackyColor/edk2/archive/edk2-stable201908.zip，这里就不需要用上面的for 4000的预处理脚本了。revert changes since rev 23091也不需要，只需要手动处理3907的情况。toolchaindirs的逻辑还是需要处理一下的，手动去掉ebuild.sh中的nasm判断逻辑，修正其它（所幸我们不需要修正22943,23089的二段）直接改名为Clover放到edk2 src下，osx下手动粘贴合并非替换，手动工作量也小，另外，mtoc也需要编译了。手动准备mtoc，里面的是cctools-921.tar.gz，但是在osx10.11.6上会出错，用回cctools-895.tar.gz，指定xcode5,因为会默认xcode8，即sudo ebuild.sh -xcode5， 出来结果，在轻量上过preboot（表现是过preboot，但提示多处patchs，一段时间会重启，preboot后卡住无提示不重启/重启无提示/出错有提示，都大有讲究。可能都与源码中的cpu处理逻辑有关），本机虚拟机也可代替5070的cloverx64.efi用。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践（8）：利用clover，离我们的目标更接近了
本文关键字：clover 黑底白苹果 无进度条,clover white screen,clover legcay bios video, clover force vesa mode, prevent Mojave switch video boot while booting,Resolution for General Protection Exception/ X64 Exception Type 0D Error 在文章7中我们讲到了使用clover来代替chameleon，因为似乎进行到上一文chameleon已经遇到了瓶颈，1，其调试功能严重不足，遇到黑屏，我们只能大致猜想是CPU不兼容或显卡乱配问题，不能从更细粒度上去确定问题所在，指导接下来实践，2，变色龙只有一种模式，即bios，通过这种方式作fake efi来（填充满足需要efi引导相关结构的OS数据块）引导黑果，因此对于现实主机/云主机功能上受制于从legcay pc的层面去解决问题，功能单一，（比如驱动）靠爬贴能得到解决问题的机会少。对于这二个问题，clover都有解决，clover可以从bios,csm,纯uefi去解决问题，提供黑果功能，有更多的驱动乱配和具备更多解决驱动带来的引导问题的方向，其调试功能一流，直接集成为工具。本文详细描述在qemu标准云主机型号（文章6，7所述命令行和libvirt版本i440fx虚拟机方案）上利用clover5070 iso引导运行黑果mojave。 前文简单描述了利用boot7做cdboot的思路，这里详述，我们利用变色龙源码来生成clover的cdboot7，注意到变色龙的srccdboot下有$(SYMROOT)/cdboot，我们复制这一段为： $(SYMROOT)/cdboot7: @echo " [NASM] cdboot.s" @$(NASM) cdboot.s -o $(SYMROOT)/cdboot7 @dd if=$(SYMROOT)/boot7 of=$(SYMROOT)/cdboot7 conv=sync bs=2k seek=1 &> /dev/null @# Update cdboot with boot file size info @stat -f%z $(SYMROOT)/boot7 \ | perl -ane "print pack('V',@F[0]);" \ | dd of=$(SYMROOT)/cdboot7 bs=1 count=4 seek=2044 conv=notrunc &> /dev/null all embedtheme optionrom: $(DIRS_NEEDED) $(SYMROOT)/cdboot后面加一条$(SYMROOT)/cdboot7,make dist前把clover的boot7放进去$(SYMROOT)，cd到src,cdboot下，sudo make all，就会发现symroot下有cdboot7了，使用这个cdboot,就加载了biosblk driver，在virtio blk下可以看到fat32中的EFI,cdboot6不行。 然后准备5070clover iso的config.plist,kexts和drivers下不动任何东西(5070 iso，kexts/other下有一个fakesmc,drivers/bios下有apfs,audiodxe,fsinject,ps2mousedxe,smchelper,usbmousedxe,xhcidxe)： 熟悉clover的调试信息与界面,虚拟机调试进系统 Clover的原则是尽量少添加参数，不懂的或不能确定其意义的不要添加(与chameleon一样他们被集成设计成尽量不必添加任何非必要参数就能启动一份常见系统，除非真的必要)，我们一步一步来，写出这个config.plist，原则是保留尽可能多的debug。而且与前文写的变色龙chameleon.boot.plist尽量一一对应，这样好理解，最终我们写成这样： <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>RtVariables</key> <dict> <key>BooterConfig</key> <string>0x28</string> <key>CsrActiveConfig</key> <string>0x67</string> </dict> <key>GUI</key> <dict> <key>ScreenResolution</key> <string>1024x768</string> <key>TextOnly</key> <true/> <key>ConsoleMode</key> <string>Min</string> </dict> <key>Boot</key> <dict> <key>Arguments</key> <string>Kernel="kernel" "Graphics Mode"="1024x768" "Boot Graphics"=No "Text Mode"=Yes -v debug=0x100</string> <key>DefaultVolume</key> <string>OSXKVM</string> <key>Timeout</key> <integer>10</integer> <key>Debug</key> <true/> <key>Log</key> <true/> </dict> <key>SystemParameters</key> <dict> <key>InjectKexts</key> <string>Detect</string> <key>NoCaches</key> <string>No</string> </dict> <key>KernelAndKextPatches</key> <dict> <key>KernelToPatch</key> <array> <dict> </dict> <array/> <key>Debug</key> <true/> </dict> <key>SMBIOS</key> <dict> <key>BiosReleaseDate</key> <string>12/22/2016</string> <key>BiosVendor</key> <string>Apple Inc.</string> <key>BiosVersion</key> <string>IM142.88Z.0118.B17.1612221936</string> <key>Board-ID</key> <string>Mac-27ADBB7B4CEE8E61</string> <key>Family</key> <string>iMac</string> <key>Manufacter</key> <string>Apple Inc.</string> <key>Manufacturer</key> <string>Apple Inc.</string> <key>ProductName</key> <string>iMac14,2</string> <key>SerialNumber</key> <string>C02KK5W9F8J2</string> <key>Version</key> <string>1.0</string> <key>Mobile</key> <false/> </dict> </dict> </plist> 解释一下： 开头，RtVariables是全局的开SIP，任何黑果引导的先决条件，为了好理解，所以把它写最前面，GUI和BOOT是菜单选单界面配置（当然，这里也有本质上的引导参数的喂给逻辑），引导后出现在你面前的就是这个界面，所以写在第二前面，GUI段面向clover作preboot用，BOOT段面向darwin接手后booting用，注意到我们加了尽可能多的debug支持的情况下，还尽量使用的是文字界面，和preboot/darwinboot一致的分辨率，这是为什么呢？ 因为chamleon或clover引导时，要么用图形要么用文字，chameleon有纯文字界面而clover只有图形模式（文字界面是图形模拟的textonly,consolemode都是图形），mojave在启动时会有二个阶段不断换分辨率，这所有的过程，都涉及到分辨率带来的显卡驱动对启动过程的影响讨论，有很多花屏，黑屏，包括前面我们说到的云机上黑屏，都可能是显卡驱动导致的，第一要素就是分辨率（vesa显驱用vesa mode）： vga std显卡vesa下mode 800x600时，clover preboot没有进度条，这就是上面GUI段手动设为1024x768以上的原因,猜可能就是800x600与匹配的vesa分辨率任何一种都不符，，逻辑上就不让过去了(要进入dmsg工具查看log中起作用的vesa mode才能发现原因可是进不去就没法使用dmsg)，为避免显卡问题在preboot时就halt掉我们的调试过程。这里应该尽量使用保守的模式（一般clover和变色龙够智能会帮你选好一般不用干预），进去mojave时，受到virtualgraphic.kext的支持，分辨率有更多选择，系统也会自己换分辨率。 所以原则上可以尽量手动保持preboot和darwinboot stage1,stage2二过程，这三个过程尽量使用一致的分辨率（如果有办法的话，比如修改源码也行，chameleon->boot2->graphics.c static int setVESAGraphicsMode中默认将vesa设为280，我将它改为267 https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Modes_defined_by_VESA，注意，vesa3支持刷新率定义但不要用，以免造成意外），这样的预先处理可以免去很多问题。所以BOOT段OS显驱发挥作用时再次喂给prelinkedkernel同样的显示模式。注意到我还喂了尽量少用graphics mode和使用text mode的参数都是为了规避可能的显卡问题(喂给kernel as flags的照样可以设置在chameleon的boot.plist中)。 此时，直到BOOT的所有配置只能完成vga std下的preboot，接下来的 SystemParameters段有大讲究，也是显示相关的，本来启动darwin后的stage1很顺利，开始切换分辨率到stage2时，花屏过不去了，后来加了虽然也会花屏，但一会就过去了，实际起作用的是SystemParameters段，我在里面加了injecexts和nocache，但实际起作用的是SystemParameters空体这句，不是里面的任何东西。而且好像它的位置也要放在下面一个平等位。比如它放在SMBIOS下面一个位就没用。而且这个空体，对vga cirrus下clover preboot也有用，不加这个空段或放到不适当位置时，vga cirrus在clover preboot时显示End random seed ++++ 白屏，而且一直没进展，加空段放到BOOT对等位下时，也是白屏，但一会就进入到stage1,stage2。直到这里为止，已完成clover的引导进入到了darwin的verbose，虽然花屏或白屏，但最终进入系统，这说明这二种显卡的vesa都生效了,cirrus进入后是800600,vga进入后是19201440，只是进入前都有瑕疵一个开始花屏，一个后面白屏(对比系统报告发现不同,clover下bios变成imac10.1，chameleon保持了按原样14.2,clover下smbios有好多是可以自动计算的，写法上可以忽略) 注意到boot段中的Log true似乎并没有生效。不如直接把dmsg.efi弄出来为tools直观,好像LogEveryBoot有用。kernel听说如果不加入此参数"Kernel=..."，将默认加载系统缓存（kernelcache）启动，作用等同于启动菜单的”without kernelcache“选项。但似乎实测证明也不正确。SystemParameters那二段(clover下没有UseKernelCache=yes，这二段组合使用模拟了类似的效果，但似乎SystemParameters二条怎么调clover都是用prelinkedkernel,换成kernel cache这个kernel flags倒是可以https://www.insanelymac.com/forum/topic/99891--/不过没必要用)，prelinkedkernel是自动-f生成或手动使用 kextcache 将 kernel 和 kexts from /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache共同 link 成 PrelinkedKernel，由System/Library/CoreServices/boot.efi启动，boot.efi 是平台特定的 EFI Driver(application), 由cloverx64.efi或真实系统的EFI 固件加载, 主要作用是加载 Kernel, 并将控制权移交给 KernelEntry.boot段中的kernel flags都是喂给/Library/Preferences/SystemConfiguration/com.apple.Boot.plist再给kernel或prelinkedkernel的。但是不要直接修改它。会造成文件系统损坏，修改这个文件很容易破坏镜像。可用clover在内存中patching。 上述启动过程中的花屏白屏，可能需要专门的驱动和patch过程来解决（vs clover，chameleon在这方面没有优势，这就是我们选clover的理由，clover可有csmvideodxe,qemuvideodxe，不过云机不能用这些，因为csmvideo需要开csm，qemuvidedxe需要开uefi，clover在mbr机上并不可以纯uefi，因此也不能使用uefi drivers，比如CsmVideoDxe-64.efi:Clover图形界面的图像驱动，可以有更多的分辨率选择。（仅限于启动界面）。他基于UEFI BIOS的CSM模块，因此需要CSM可用。UEFI GOP VBIOS只适用于UEFI引导的系统的,即UEFI引导的Clover和Ozmosis,用传统BIOS引导系统的同学请绕行）。不过不对引导造成问题，我们就不管了。 搜索花屏白屏，在网上可以爬到很多贴，单一个黑屏就这么多可能和可能的解决方案。也是初学者学习黑果第一大拦路虎，这里有趣也最容易让人弃坑，黑苹果文化博大精深，到底都是方案，可是不一定适用你那套。 我们可以在GUI段通过custom和scan将dmsg.efi工具形成菜单。查看debug log就更快捷了。跟Uefishell一样，Uefishell,就是把启动脚本化，而且是在线脚本语言化，跟grub一样，接上shell，都可以。但可运行一些.efi程序,load一些驱动，cp,ls一些文件，注意与cloverx64分开，它不可用于引导OSX，cloverx64才是osx lister和OS X booter efi(boot6,7 is the booter itself)，osxclover提供了二个efi booter，其实都是同一个文件，就是bootx64和cloverx64，如果充分利用CLOVER，甚至可以打造装机上的“统一实机云主机firmware”和统一BOOT环境,让bootx64是总boot。也许我们以后要把各种OS（包括boot6,7）做成boot+pbr，做成各种os的loader文件，让所有fat32 boot下的所有boot都呈一个样归进EFI. 云主机上的clover通用保护错误和黑屏问题 如果说实机上的白屏，花屏不影响最终启动，那么云主机上的黑屏就是一个实实在在的先决问题了。这之前，还有一个错误，就是cloverx64在云主机上执行会报错General Protection Exception/ X64 Exception Type 0D Error。这是clover层面的导致出错。但也有可能是显卡导致的。The reason is the incompatibility between UEFI graphic drivers & OS（or boot loader）.cloverx64只是相当于Os lister+它可以引导osx,Cloverx64一开始在preboot就用了显卡驱动，不像变色龙在preboot用的是text console。由于大量使用vesa，所以它访问graphics driver时会发生type 64 exception通用保护错误。而变色龙往往在完成preboot启动后，darwinboot接手涉及到大量vesa时才会黑屏，既然从clover中得知，黑屏可能不是cpu而是从qemu模拟的vga（vgabios inside seabios）到os显卡驱动导致的，本地就不黑，云主机就黑，clover也是切换到这种图形模式就无法输出了，那么这样这种某种cpu保护错误还与显卡问题同源。 那么，最终这是CPU兼容问题还是第一节显卡问题在云主机特殊环境上的新问题？如果我们在chameleon有限的debug下看不到，那么在clover下丰富的debug支持下能不能看到问题的蛛丝马迹呢？ 不过，可以肯定的是，clover下解决问题尝试的方向会有很多，在源码定制上，它基于omvf实现，有很多开源驱动可以定制，摆弄，众多黑果开发者维护了很多驱动成果。可寻求解决问题的尝试路径会更多。 让我们试目以待。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践（7）：继续处理云主机上黑果前后置问题，增加新boot
本文关键字：fakecpuid apple logo stuck,变色龙fakecpuid,Cascadelake fakecpuid,qemu define cpu model,Skylake-Server qemu hackintosh 我们知道，云上能启动黑果是上下一条路径上包括硬件，bios,boot,os在内合力的效果，硬件上的CPU又是这条路径上产生变数最多的因素，变色龙处理cpu兼容是一关，kernel处理cpu兼容是它独立的一关，这二个都存在这样的过程。而变色龙与kernel对cpu的定义不一样，存在不一样的处理过程，所以可能导致不能把cpu信息传给kernel最终发生黑屏这样的过程（更何况硬件/模拟器上，qemu对指令集和CPU支持也不一样），因此我们需要重新全盘统筹。 新的qemu和新加的boot 如何判断阿里云上qemu的版本？除了搜索引擎，也许只有实测靠谱，如何在guest体内判断host的qemu版本。好在阿里会把qemu版本信息写在系统里，我们在轻量上执行dmidecode，出来BIOS Information Vendor: SeaBIOS Version: 8c24b4c Release Date: 04/01/2014，System Information：Manufacturer: Alibaba Cloud Product Name: Alibaba Cloud ECS Version: pc-i440fx-2.1。 因此我们重新编译qemu with deepin1511中的gcc630： wget http://wiki.qemu-project.org/download/qemu-2.1.0.tar.bz2 sudo apt install libpixman-1-dev bison flex libsdl-dev autoconf automake libtool (不加sdl会卡在vnc server，注意这里是sdl不是sdl2) (不加auttools会autoreconf: not found，不加flex bison在install时会出错) ./configure --prefix=/usr --target-list=x86_64-softmmu --enable-sdl make install 这个出来的bios是BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org，离20140401很接近了。就这样吧。这样qemu版本就适配了 除了qemu，enoch2922本身就是个问题，因为其中根本就没有对最新cascadelake的定义和支持，查看src/libsaio/platform.c,platform.h我们看到它支持的CPU和指令集，三src驱动高重我们的调试思路是确保这三者从上而下，都有同样的关于cpu正确逻辑的继承实现或屏蔽（或者像Penryn一样能启动就行，可能仅仅因为cpu的问题在这这三者不冲突）。但另一个有名的boot：clover可能有: Clover is a later revision of Tianocore. Both are 'firmware in RAM' replacements for UEFI firmware.It allows you to boot in MBRCSM mode and then run Clover which acts as a 'pseudo-UEFI boot manager', allowing you to boot to a UEFI OS from an MBRCSM boot.2015-10-16 Rev 3289 新增 Skylake CPU 及 核显 及 SMBIOS 支持。而且，clover更强大有更先进的gui wizard，高于mbrpatch指定的Clover r4514+ boot 10.14 fine的版本选择也多，clover下也有直接把log保存在第一个分区的功能（而变色龙仅能得到bdmdg，Bdmsg其实是仅直到变色龙启动完就停止的。/var/log/system.log下有kernel启动的log）。不妨再添加一个boot同时测试？ 尝试再添加一个boot为四叶草，直接从http://sourceforge.net/projects/cloverefiboot/files/Bootable_ISO/下载以wowpc.iso同样的方式启动。我们知道clover同时支持引导bios和uefi，也可以在实机或qemu（+pc-i440fx）下启动https://passthroughpo.st/hackintosh-kvm-guide-high-sierra-using-qemus-i440fx-chipset/，一般地，我们使用grub2+memdisk+clover.iso这种干净的老方案（网上还有把clover做成dmg，或grub chainloader boot0ss文件或chainloader pbr文件的方案），然而最新的clover.iso在qemu（+pc-i440fx+hd or virtio）时，会在引导clover时进入一个头部带有上述dmidecode部分信息的图形化虚拟UEFI BIOS 启动界面（这实际上是没有发现盘，因此无法加载EFI文件夹，因此无法加载/EFI/BOOT/BOOTX64.efi这个bios启动文件，在图形化efi界面文件浏览，你也根本看不到盘符），这实际上跟clover iso版本采用的boot也有关系（clover iso有一个cdboot，这相当于clover install较旧版本的默认boot，clover install较新版本没有默认boot，只有多选方案，但也只有二个，一个boot6,一个boot7，Clover ISO cdboot集成的默认是boot6，boot6,7启动效果不同），跟盘性质也有关系(一般clover更好支持bios+gpt+普通ide+fat32，当然它也承诺支持bios+mbr+hfs+)，跟你的硬件/qemu也有关系(除非你编译qemu2.1时加了CONFIG_VIRTIO_BLK_DATA_PLANE，否则virtio在bios下是无法识别的，grub2 insmod hfs hfsplus part_apple ->memdisk>clover.iso也不能把这种效果传递给clover。) 我们最终选择是Clover-v2.4k-4630-X64.iso，分别在实机下测试和云上测试，盘性质为普通ide hd，且EFI位于这个分区内，可以进入到clover选单界面，不受支持的virtio就只能停在图形化efi界面，如何实现让其在virtio或云机上也能用呢？。 我们直接dd把文件弄出来，也不用去编译clover的源码了。Cdboot:452,608-boot6:450,048=2560字节Byte，512Byte是1簇，是5簇把cdboot与boot7放一起：然后 dd if=boot7 of=cdboot seek=5 bs=512 conv=notruncFat32 BOOT根分区是不需要放BOOT文件的,只需要把EFI从ISO中复制到这里来，其实移动也可。(对比变色龙，EFI就相当于其Extra)然后mbrpatch cfg用变色龙那套Remaster Clover ISO 测试可以启动。以后我们就变色龙和四叶草一起测试了。如果你想测试clover install pkg，或得到相关文件，在10.12,13虚拟机guest osx中进行，，复制过去osxkvm10146然后挂载这个raw image,安装到虚拟出的boot区得到相关文件。，不要在host osx中安装（有保护也装不上）也不要在guest osx本机中安装。如果你想替换clover.iso，直接在host osx端挂载raw image编辑boot区放入新调的clover.iso(修改完成不需要卸载，pd端就能反应出变化)，用不着一台具有网络能力的qemu tcpe了。 新的libvirt xml和boot.plist 我们为什么deprecate前文qemu4.2的思路，前面的增删指令集思路没用，因为一个CPU涉及到架构，不是简单的指令集的叠加。因此我们从别的方向前进。我们用上了libvirt xml和vnc，我们使用libvirt是看中了它能自定义cpu，这样我们可以坚守在2.1下，一步一步自定义cpu成skylake或Cascadelake: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>osxkvm</name> <os> <type arch='x86_64' machine='pc-i440fx-2.1’>hvm</type> </os> <features> <acpi/> <kvm> <hidden state='on'/> </kvm> </features> <cpu mode='custom' match='exact' check='none'> <model fallback='allow'>Penryn</model> </cpu> <memory unit='KiB'>4194304</memory> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <input type='keyboard' bus='usb'/> <input type='mouse' bus='usb'/> <video> <model type='cirrus'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <graphics type='vnc'/> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/media/psf/DATA/aliyunosx/osxkvm10146'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <interface type='bridge'> <mac address='52:54:00:c9:18:27'/> <source bridge='virbr0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x0' slot='0x03' function='0x0'/> </interface> </devices> </domain> 网络还是用回文章1的tap0而不是使用helper，因为我们想免去boot.sh sudo ip tuntap add dev tap0 mode tap sudo ip link set tap0 up promisc on sudo brctl addif virbr0 tap0（这句跟xml中bridge chunk中的target作用重复,如果不删掉<target dev='tap0'/>你每次都需要sudo brctl delif virbr0 tap0,PD一旦休眠或暂停，tap0会自动消失因此这个绑定作用失效需要重新执行然后把virbr0停止再开一下，所以测试过程中要把pd中deepin设为永不休眠，否则qemu tcpe网络不稳定) 继续作源码修改强化变色龙的调试功能： 因为10.14开始已经不支持32 sdk了。所以最新可用的10.13，PD直接application下的安装app直接做成镜像，过程中要产生一个cdr，这个原理就是我们在文4中提到的，其实可以手动直接createinstallmedia产生供pd使用的可安装镜像,只是在10.15不能执行32位createinstallmedia，制作好的安装程序已损坏，暂时更改主系统的time，例如date 102516242016回车,并禁网络直到安装完成(guest中这样做比较麻烦第一阶段可以过去，但第二阶段选不到菜单调不出命令行，过不去) 10.13支持的是Command Line Tools (macOS 10.13) for Xcode 9.2.dmg，它也没有10.11 command tools下不支持c99 vsscanf等函数发生“ld vsscanf : symbol(s) not found for architecture i386”等的问题: graphics.c中Bouncing ball .oOo.把动画图标换成文字小棍。prompt.c中加个by 自己的标识前面说到变色龙的bdmsg就是信息内容复杂点的-v + pause()，它其实是#define DBG(x...) msglog(x)，可以改动把它保存在可访问的fat32 boot分区内。 sys.c long GetFileInfo，可以得到文件名，用于hfs.c中提取更简单的文件名，你也可以在hfs.c中用vsscanf正规提取*.kext的部分，-v最后出现的加载drive，只要在启动时命令行中同时指定UseKernelCache=No才出现，变色龙默认使用prelinkedkernel，也就是usekernelcache=yes(-f=Yes)，此时不加载s/l/e，一定要指定usekernelcache=no才加载 在qemu src的pcbios下，我们找到acpi-dsdt.aml(i440fx),q35-acpi-dsdt.aml，变色龙也支持DSDT，因为变色龙逻辑中只写了bt(0,0)而我们的dsdt.aml在en(0,0)中，所以丢到extras还不够，还要在boot.plist中写一条key DDST,string dsdt.aml 其实变色龙也支持和clover一样的自定义kernel patch。在kernel.plist中写KernelPatches,blaaa.. 二个boot，调试cpu尝试让mojave在Skylake-Server下运行解决黑屏问题 Clover和变色龙下，cpu设为Penryn可进入我们前面做好的镜像。但换cpu就进不去。这也在意料之中，cpu不兼容。继续看一段关于处理CPU兼容的问题，你可以三者全实现也可以保持不冲突部分实现，只要能最终启动mojave： Why Penryn is recommanded beforehttps://forums.unraid.net/topic/84430-hackintosh-tips-to-make-a-bare-metal-macos/: After digging a lot of code, I have some conclusions why they recommanded Penryn as prefered CPU Model: Penryn is classic, and it missing some features compared to newer generation, which lead to a similar situation with VM. Penryn do not have a msr 0x00000198 leaf to read the perfstatus (like bus ratio, cpu frequency) which the same as a VM. Penryn do not have a msr 0x35 leaf to read topology structure, which also most hypervisors haven't implemented yet.Instead, the MacOS will try to get the topology from acpi when it detect a Penryn process, which the same as a VM. Some bootloaders do have some compatibility issues when using a newer generation in a VM, some causing dividing by zero errors(They can't get correct frequency from acpi or msr, so they may be zero). Some articles have outdated so long from now. It don't have some cpuid features like avx/avx2/bmi/fma so MacOS won't recognized those features even thought you just passed through. osx下的cat /proc/cpuinfo：sysctl machdep.cpu，sysctl -a | grep machdep.cpu，sysctl -a | grep hw.optional 更多在clover和变色龙下patch cpu的选项和功能：https://github.com/AMD-OSX/AMD_Vanilla/blob/master/17h/patches.plist： <string>algrey - commpage_populate -remove rdmsr</string> <string>algrey - cpu_topology_sort -disable _x86_validate_topology (10.14.4+)</string> <string>algrey - cpuid_set_generic_info - disable check to allow leaf7</string> <string>algrey - cpuid_set_cpufamily - force CPUFAMILY_INTEL_PENRYN</string> <string>xlnc - cpuid_set_cpufamily - force CPUFAMILY_INTEL_PENRYN</string> <string>algrey - i386_init - remove rdmsr (x3)</string> <string>algrey - tsc_init - remove Penryn check to execute default case</string> <string>algrey - tsc_init - grab DID and VID from MSR</string> <string>xlnc - tsc_init - grab DID and VID from MSR</string> <string>algrey - tsc_init - skip test and go get FSBFrequency</string> <string>xlnc - tsc_init - skip test and go get FSBFrequency</string> <string>algrey - lapic_init - remove version check and panic</string> <string>algrey - lapic_interrupt - skip checks and prevent panic</string> <string>xlnc - lapic_interrupt - skip checks and prevent panic</string> <string>algrey - mtrr_update_action - fix PAT (x2) (10.14.4+)</string> 很不幸，这篇文章依然不是《最终实现在云机上运行黑果》，依然是前文的继续，我们的目的只是把osx装上云当个nas，代替《聪明的Mac osx本地云》文使之成为iphone,osx的nas mate os，可能这种尝试有点付出太多了。但无论如何，读到这里的小伙伴都赢了：目标已经十分接近了。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践（6）：处理云主机上变色龙启动后置过程：驱动和黑屏
本文关键字：无显驱vesa方式驱动osx10.14,mojave vga黑屏，云主机的显示器，非n非a卡黑果，waitting for root device，apfs modules stop 1432,appleexclude.kext，can't determine on the same uuid,qemu virtual display,qemu vga glitch，starting darwin x86就黑屏, osx cascadelake 黑屏, 变色龙 skylake 黑屏 在前面5篇系列文章中，我们讲到了云上装黑果的基础工作和碰到的前置调试问题，我们采取的是用本地尽可能接近阿里云参数的情况下模拟镜像在阿里云端可安装运行（安装镜像/安装，安装后镜像/运行）的测试路径，假设这些工作完成之后，就可能肯定基本离成功在阿里云轻量上运行黑果这个目标很接近了，文1到文5中间做的都是顺利的准备工作，除了准备镜像都是前置启动故障排解，文章5末尾我们描述的一些1,驱动调试相关的问题和2,虚拟机不黑/轻量云黑屏的特别情况，这些都属于变色龙启动后darwin开始接手的地方，属于后置过程了，进入到机型适配了，被普遍认为是机型适配碰到的BOSS级的问题，本文开始，继续文5提到的问题排解和调试，其中有一条是在i440fx下我们无法从virtio blk驱动，因此也无法从其中的系统启动，启动中出现waitting for root device（我们初步判断这种问题有可能是前文说的pci功能位不对，也可能往往是驱动加载不正确，启动不起来，不要动不动就联系到AppleAHCIPort）。 这是因为文章2-4适配的是安装后镜像，是正确的路径，但到了5我们企图得到一个安装镜像，偏离我们原来的测试路径，其实，安装与运行，这二者不能二全，installer镜像是不含任何virtio和virtualgraphics驱动的，安装后的镜像才有，只要我们在qemu配置文章中手动加入功能位，而且使用没有受破坏的安装后的镜像，即，在变色龙启动完成后的kernel verbose界面保证不出现显示virtio驱动加载错误（如果你强行把virtio,virtgraphics相关和依赖kext丢进E/E或S/L/E，这往往又破坏镜像加的权限和缓存，照样会出现apfs modules stop 1432，修复往往不起作用），就可以实现识别virtio blk驱动，从其中启动的，而cirrus-vga显卡驱动，在启动时有花屏，进入系统后却是可以识别并驱动的（只是是800x600模式的SVGA兼容模式，此模式由VESA为IBM兼容机推出的标准。分辨率为800x600，查看设备为00:02.0 "Class 0300" "1013" "00b8" "1af4" "1100" ，1013 Cirrus Logic，00b8 GD 5446，1af4 1100 QEMU Virtual Machine，这说明virtualgraphic也发挥作用了） 驱动问题并没有发展到需要patch kext处理显卡驱动，更没有涉及到加起QE/CI显卡加速来，因为我们是云主机无须显卡加速，但黑屏依然是一个暂时无解的问题，可能是CPU指令集问题，也可能是黑屏与修改edid法修复显示器参数,dsdt法，但这些都可以作为猜想，都需要慢慢找出问题。 重整理的测试参数 我们重新设计一下测试参数： 创建安装镜像cdr: hdiutil create -o "osxkvminstall10146" -size 8g -layout SPUD -fs HFS+J hdiutil attach "osxkvminstall10146.dmg" -noverify -nomount diskutil partitionDisk disk2 MBR JHFS+ OSXKVMINSTALL R 直接用mbrpatch脚本免Q5Q6，不要手动复制basesystemdmg/s/l/e或pacifist解压，否则有权限问题，会导致apfs module stop 及时安装变色龙启动,这个dmg和cdr卸载后会变成只读，所以尽早安装变色龙, hdiutil convert "osxkvminstall10146.dmg" -format UDTO -o "osxkvminstall10146" 创建安装后镜像： dd if=/dev/zero of=osxkvm10146 bs=512 count=52428800 hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount osxkvm10146 diskutil partitionDisk disk2 MBR fat32 BOOT 100M JHFS+ OSXKVM R （mbr的在安装后的osx不可动态调整因此没有必要在尾端保留一个osxinstaller，做成osxkvm,osxkvminstall镜像为一体，用尽25G） fdisk -e /dev/rdisk3,flag 1,write,yes,quit。 在linux中安装grub2,syslinux,tcpe,wowpc 用这套安装,按esc进,用cdr上的启动就可以避免安装时osxkvm所在卷不可卸载: qemu-system-x86_64 -enable-kvm \ -machine pc-q35-2.8 \ -cpu Penryn,kvm=off,vendor=GenuineIntel \ -m 5120 \ -usb -device usb-kbd -device usb-mouse \ -device ide-drive,bus=ide.2,drive=MacHDD \ -drive id=MacHDD,if=none,format=raw,file=./osxkvm10146 \ -device ide-drive,bus=ide.0,drive=MacDVD \ -drive id=MacDVD,if=none,snapshot=on,file=./osxkvminstall10146.cdr \ -boot order=dc,menu=on 用这套启动安装后的系统，注意去掉了smp，且其中新手动加的pci插槽和功能位,tcpe下lspci就能看到: qemu-system-x86_64 -enable-kvm \ -machine pc-i440fx-2.8 \ -cpu Penryn,kvm=off,vendor=GenuineIntel \ -m 5120 \ -device cirrus-vga,bus=pci.0,addr=0x2 \ -usb -device usb-kbd -device usb-mouse \ -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=MacHDD \ -drive id=MacHDD,if=none,cache=writeback,format=raw,file=./osxkvm10146 \ -device virtio-net-pci,bus=pci.0,addr=0x3,mac='52:54:00:c9:18:27',netdev=MacNET \ -netdev bridge,id=MacNET,br=virbr0,"helper=/usr/lib/qemu/qemu-bridge-helper" chameleon.boot.plist中删掉： <key>UseKernelCache</key> <string>Yes</string> 启动的时候一定要手动打上UseKernelCache=Yes，否则还是识别不了virtio,-v 可以看到识别了virtio blk，在Rebuild caches after update，early boot complete,continue后会出现：notice - new kext com.apple.driver.kextexcludelist, v14.0.3 matches prelinked kext but can't determine if executables are the same (no uuids)，等漫长的timeout之后(我等了五分钟)。可进界面（又是漫长的左上角滚动海浪球），下次启动不会等这么久。 完成！可顺利加载virtio和显卡驱动进入系统，封装osxkvm10146为gz，上传到云主机。你可以把那个第一次进入等待过久的过程固化在镜像中打包，云机中以后就不用等这么久了。 至于如何让Applevirtio手动变成一个boot time driver集成在install镜像或osxkvm镜像中免去使用这个prelinked kernel(一般情况下避免使用prelinked cache,-f是用来强制重新从磁盘s/l/e加载kext跳过缓存的。但并不会重建prelinked缓存，注意把kext与kernel的缓存分开)，我尝试把kext提到变色龙或s/l/e,权限修复工具，手动修复，kextcache 实现的几种方法都无效，KCPM Utility Pro，kext utility 2.6.1这类工具无法给离线系统注入kext，更提示无法给恢复系统注入kext和make cache。都没有成功。 对cache机制的理解： The kernel is the first component of the operating system to start. It has no other tools available. In particular there is no way to check code signatures, and all file system access is very hard at this point. Apple therefore decided to prelink the bare kernel with all kernel extensions every time the kernel or one of the extensions is updated, and to start only that prelinked kernel at boot time. Since the prelinked kernel is on a read-only volume, it cannot be updated directly. Apple had to conceive a new mechanism for updates. When you reboot or shut down your machine, launchd stops all processes. Then it remounts the system volume in read/write mode. This is possible because launchd has the entitlement com.apple.private.apfs.mount-root-writeable-at-shutdown. Then it runs /var/install/shove_kernels to copy the new kernel.But apparently this doesn’t actually work. So to update a kernel extension you need to disable System Integrity Protection or manually trigger a kernel update after booting into macOS Recovery. Note: This is fixed in macOS 10.15.1 我用的脚本： #!/bin/sh sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo rm -Rf /S*/L*/PrelinkedKernels/* sudo rm -Rf /S*/L*/Caches/com.apple.kext.caches/* sudo touch -f /S*/L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / 驱动解决，也不用考虑安装镜像和安装问题，接下来只需探索黑屏问题。 云主机变色龙黑屏探索1：cpu兼容 我们在上文说到，在云轻量上，变色龙读取s/l/e，加载完plist和kext中的可执行文件，直到TMsafetyNet.kext ，从这里开始就黑屏了(控制台可以看到磁盘和CPU都没有读写，应该是halt了。而不仅是虚拟vnc显示器没有信号)，我们上文也讲到Wait=Yes不起作用，可能也是在执行wait=yes前就黑了，因此我们有必要修改变色龙源码，在结束-v所有输出98%内容后输出starting darwin kernel前（或许是判断文件名tmsafetynet后），每条输出都pause一下，看到底在哪里黑屏了。 上面的qemu启动配置，就cpu和display没有真正做到与云轻量对应。如果没有cpu直通，kvm虚拟出来的是vcpu，客户机看到的是基于 KVM vCPU 的 CPU 核，而 vCPU 作为 QEMU 线程被 Linux 作为普通的线程/轻量级进程调度到物理的 CPU 核上。 进轻量云，tcpe cat /proc/cpuinfo，对于cpu，我们发现CPU是变化的，有时是Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz（Cascadelake），有时却是：Xeon Platinum 8163（SkyLake），这是一个1C的主机：processor: 0，physical id: 0，siblings: 1，core id: 0，cpu cores : 1，也可以看到它的feature指令集。 我们cpu设为最基本的客户机 CPU 模型qemu64,把所有的cpu flags都加上。后面加check,enforce来查看与host的比较情况，最后上面的cpu变成： -cpu qemu64,kvm=off,vendor=GenuineIntel,+fpu,+vme,+de,+pse,+tsc,+msr,+pae,+mce,+cx8,+apic,+sep,+mtrr,+pge,+mca,+cmov,+pat,+pse36,+clflush,+mmx,+fxsr,+sse,+sse2,+ss,+ht,+syscall,+nx,+pdpe1gb,+rdtscp,+lm,+constant_tsc,+rep_good,+nopl,+pni,+pclmulqdq,+ssse3,+fma,+cx16,+pcid,+sse4_1,+sse4_2,+x2apic,+movbe,+popcnt,+tsc_deadline_timer,+aes,+xsave,+avx,+f16c,+rdrand,+hypervisor,+lahf_lm,+abm,+3dnowprefetch,+fsgsbase,+tsc_adjust,+bmi1,+hle,+avx2,+smep,+bmi2,+erms,+invpcid,+rtm,+mpx,+avx512f,+avx512dq,+rdseed,+adx,+smap,+avx512cd,+avx512bw,+avx512vl,+xsaveopt,+xsavec,+xgetbv1,+xsaves,+arat,check,enforce 放在本地启动，发现2.8的qemu-kvm -cpu help，Qemu Recognized CPUID flags，是不支持以下的：qemu-system-x86_64: Property '.constant_tsc' not foundqemu-system-x86_64: Property '.rep_good' not foundqemu-system-x86_64: Property '.nopl' not foundqemu-system-x86_64: Property '.tsc_deadline_timer' not found 而且，我的主机cpu是不支持以下的（这并不影响什么，只要qemu支持模拟就对我们的实验结果没有影响）： warning: host doesn't support requested feature: CPUID.01H:EDX.ht [bit 28] warning: host doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9] warning: host doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] warning: host doesn't support requested feature: CPUID.07H:EBX.mpx [bit 14] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512f [bit 16] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512dq [bit 17] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512cd [bit 28] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512bw [bit 30] warning: host doesn't support requested feature: CPUID.07H:EBX.avx512vl [bit 31] warning: host doesn't support requested feature: CPUID.80000001H:EDX.pdpe1gb [bit 26] warning: host doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] warning: host doesn't support requested feature: CPUID.0DH:EAX.xgetbv1 [bit 2] warning: host doesn't support requested feature: CPUID.0DH:EAX.xsaves [bit 3] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 3] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 4] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 5] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 6] warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 7] 暂时先在上面的cpu指令集中删掉以上4条。正常启动Qemu，果然，这个cpu下发生了黑屏，跟云机表现一致,重新在deepin15编译qemu高版本，QEMU 3.1.0 in added the Cascadelake-Server CPU,我们下载的4.2.0： sudo apt install libpixman-1-dev bison flex libsdl2-dev(不加这个会卡在vnc server)./configure —prefix=/usr —target-list=x86_64-softmmu —enable-sdlmake install cat /usr/share/libvirt/cpu_map.xml |grep Cas -A100，发现有Cascadelake-Server，但是我们不把cpu指定为cascade lake-Server，我们更相信指定具体的指令集，删掉的4条可以加上了，重新运行qemu，可以运行，但依然会出现host cpu缺失指令集warning，虚拟机表现同样黑屏，跟云机一致。 看来，这个CPU太先进了，只能尝试CPUID fix了（如https://www.insanelymac.com/forum/topic/335650-kernelandkextpatches-1013x1014x1015x-x99x299/），就跟处理前面的msrs一样，变色龙集成了一部分cpu patch，但需要我们做更多工作。不能确定是哪个指令集缺失或什么其它原因导致的问题，多开几台不同CPU的云主机试试，或者在本地不断调整指令集参数作Clear Test测试，然后在相关kext处作patching针对解决。 云主机变色龙黑屏探索2：虚拟显示器注入 在探索1提到，驱动和显示器问题可能并不是黑屏的原因(nv_diable让vesa生效没用,radvesa没用，删s/l/e驱动让Vesa生效也没用，一般不必也导致权限问题，resolustion915 fix也不是)。安装过程中花屏和vnc中glitch现象（https://ostanin.org/2014/02/11/playing-with-mac-os-x-on-kvm/）是24位与36位混乱形成的，但不影响进入系统(想到这里，突然也记起以前用向日控控的时候，笔记本有屏幕，需要拔掉，才能那个网络界面中显示,控控对台机好用自配屏的笔记本不行)。但为了完善我们的测试过程，我们还是考虑可能的显示器edid问题： The EDID (Extended display identification data) data structure have all the info of your graphic card and other video sources.EDID是由VESA——视频电子标准协会定义的，并在1994年和DDC标准1.0版一起推出了1.0版本，qemu也支持以下虚拟显示器： -display sdl - Display video output via SDL (usually in a separate graphics window).-display curses - Displays video output via curses.-display none - Do not display video output. This option is different than the -nographic option display vnc, 这就是我们云机支持的， 再看几条爬贴参考： https://www.tonymacx86.com/threads/black-screen-after-boot-menu.165117/ https://www.tonymacx86.com/threads/guide-general-framebuffer-patching-guide-hdmi-black-screen-problem.269149/ 新版本的qemu支持edid，但是云主机的qemu是我们无法控制的。考虑这条方向上的尝试不实用。总之探索2最好在探索1完成后再进行。 ————— 也许我们以后要深度修改变色龙源码，把usekernelcache固化进变色龙，或加入云专用的kexts，定制一下whatevergreen之类的东西与云主机适配，修改resolustion src为cirrus logic vga所用。尽量避免动到镜像本身。还有那个msr ingore问题，希望在变色龙端彻底解决：msr 0x35 which qemu/kvm not implemented yet then ..mojave和catalina都越来越大了，未来精简osx为更小的镜像比如至仅命令行。据说还有mojave，AppleQEMUHID.kext… (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践（5）：重得到镜像和继续强化前置启动过程
本文关键字：,hackintosh Cirrus Logic GD5446，OS X,GD5446 kext，黑苹果 vga兼容 花屏，黑苹果 虚拟机 显卡驱动 现在是4.4全国哀悼日，没有从天而降的超人只有敢于挺身而出的凡人 在前文中，我们解决了大量启动测试前的关键问题，但还不算进入了真正的黑果适配机型的关键步骤，因为有一些前置问题依然存在，1，关于前文那个编译后的变色龙有时在grub2+memdisk下启不动的问题，有没有永久解决法，有没有解法使kvm的ignore_msrs在guest端实现？2,鉴于前面文章提到的云机适配问题，有没有方法在qemu中尽可能虚拟出接近云的guest配置，在本地深度测试后再上传镜像3，我们在前面编译的trunk2922不是enoch的，跟社区的chris1111（能用于在文章2,3中正常安装启动的boot,cdboot）的boot存在大小相差，引导效果也不一样，前者启动后只进行了很小的起步。尝试chris1111(基于enoch)的可以进行到更多的进度,不加EasyMBR A5,A6可进系统。4,在镜像中放installer还是完成安装后的osx，osx有没有类winsetup的驱动部署过程。5,Mojave 1014是否真正选型正确？是否搭载了必备关键驱动。留给我们的工作多不多，有没有不可克服的？6,是否有改用clover的必要？ 我们将继续一一处理： 新qemu配置方案 对于1，暂时没找到永解法，但找了一个新的暂时解法，把linux16,kernel16后面的16删掉ctrlx会halt，然后重新启动，系统进入到变色龙的概率会更大， 对于2，，一般的qemu/osxkvm用的都是q35机型，云主机是1996年的if440x，这种芯片影响了osx的支持设备，与能不能启动直接相关，比如机型的插槽都绑有具体功能，if440x不支持pci上的virtioblk启动iso，会卡在waiting for root device这是硬件导致It doesn't boot with the disk in virtio and scsci-virtio mode but boot in scsi.（启动分二段，第一段是变色龙的启动，稍后会详细说明kernel之后的启动调试也有卡root这里仅是变色龙启动），变色龙检出Cpu is intel xeon platinum 8163 cpu,Intel Xeon Platinum 8163（Skylake）,这是阿里云第四代服务器采用的CPU，但本机模拟不出这种U，vga不能用std，只能用cirrus-vga,但这种显卡在虚拟机中实测启动花屏，但安装过程依然可辨，在云主机上直接黑屏不能继续调试，但还是努力尝试一下，找出一套尽可能在保留if440x全局设定下启动osxinstaller的配置（毕竟阿里云不能改，其它的可以通过在osx端和变色龙端软性更改，比如尝试让virtio在osx端发挥作用前面说到这属于kernel之后的启动调试后来解决），所以以下，硬盘加了achi，显卡暂时没处理： qemu-system-x86_64 -enable-kvm \ -machine pc-i440fx-2.8 \ -smp 4,cores=2 \ -cpu Penryn,kvm=off,vendor=GenuineIntel \ -m 4096 \ -usb -device usb-kbd -device usb-mouse \ -device cirrus-vga \ -device ahci,id=ahci \ -device ide-drive,bus=ahci.0,drive=MacHDD \ -drive id=MacHDD,if=none,format=raw,file=./osxkvm \ -device virtio-net-pci,mac='52:54:00:c9:18:27',netdev=MacNET \ -netdev bridge,id=MacNET,br=virbr0,"helper=/usr/lib/qemu/qemu-bridge-helper" \ -boot order=dc #暂时不支持未实现 #-device virtio-blk-pci,drive=MacHDD \ #-drive id=MacHDD,if=none,cache=writeback,format=raw,file=./osxkvm \ #使用bridge网络,对于网卡，主机要有tap0先行创立起来，记得启动virtmanager中的那个virbr0哦，最好设为自动启动onboot，上面的device前drive后端定义才起作用。osx支持virtio net才起作用。 sudo chmod u+s /usr/lib/qemu/qemu-bridge-helper mkdir /etc/qemu touch /etc/qemu/bridge.conf echo 'allow virbr0' > /etc/qemu/bridge.conf #简单起见，除了ahci,pci都没有写slot位，功能位等，有默认值也可手动boot进tcpe。tce-load -wi pci-utils.tcz，然后lspci或lspci -t：以树状结构显示PCI设备的层次关系，包括所有的总线、桥、设备以及它们之间的联接,pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2' 有四个域，或lspci -nn，或命令是lspci -vmm查设备ID与供应商ID，然后填上,我看到的是vga2 nic3 hd5 未来考虑使用Libvirt xml file format 新enoch变色龙 对于3，我们需要重新checkout编译enoch branch的源码而不是trunk的(变色龙作为Appleboot https://opensource.apple.com/release/macos-10133.html和开源系统OpenDarwin的继承被社区用来作引导白果，通过KernelPatcher和FileNVRAM，变色龙已经支持纯白苹果免改iso只在内存中patching的安装方式https://www.insanelymac.com/forum/topic/299296-kernelpatcher-source-code/)，除了enoch branch,Chimera是另外一个有名的branch,变色龙 Enoch r2880 版本起 功能 变更如下: 1.内嵌入 FakeSMC.kext 2.新增 KextsToPatch,使用文件 /Extra/kexts.plist 3.新增 KernelToPatch,而trunk2922依然没有这些。它的kernelpatcher module和filenvram是外置的（vs enoch内置的功能很欠缺内置只有一个acpi patcher，而且丢进extra/modules，会卡在tmsafey.kext或AppleKextExcludeList.kext ）,启动时没有 KERNEL PATCHER START 。好多都没有发挥作用，—— 奇怪的是，它的make pkg结果居然是有跟enoch 2922一样的kernel patcher项的。有趣的是，我发现chameleon也有menuconfig。 svn -co HEAD http://forge.voodooprojects.org/svn/chameleon/branches/ErmaC/Enoch,Makerule中的CFLAGS = $(CONFIG_OPTIMIZATION_LEVEL) -g -Wmost -Wno-expansion-to-defined中的Werror去掉,修改一些源码加入从enoch删掉的-v debug部分： 在boot2/boot.c中能发现verbose(）的地方加个if (gVerboseMode) pause(); // ErmaC verbose("\n"); if (gVerboseMode) pause(); kernel_patcher_internal.c中： verbose("[ KERNEL PATCHER START ]\n"); if (gVerboseMode) pause(); verbose("[ KEXTS PATCHER START ]\n"); if (gVerboseMode) pause(); 把加载kext的详细过程verbose出来并适当停顿，因为有时候在这里也会发生黑屏，卡屏，重启情况。这样肉眼可以看到。 drivers.c中： verbose("Attempting to load drivers from standard repositories:\n"); if (gVerboseMode) pause(); verbose("Attempting to generate and load custom injectors kexts:\n"); if (gVerboseMode) pause(); 我们把加载kext的verbose也做出来,并且10条一暂停。Enoch的Hfs.c里面Read HFS+ file被注释了，我把把它弄回来，依然在drivers.c中,这几句放FileLoadDrivers（）index=0和 ret=getdirentry开始处: index = 0; int plistverbosecount=0; while (1) { if ((plistverbosecount > 9) & gVerboseMode) { pause(); plistverbosecount = 0; } plistverbosecount++; ret = GetDirEntry(dirSpec, &index, &name, &flags, &time); … } …. } 这几句放long LoadMatchedModules( void )处: int exeverbosecount=0; while (module != 0)内： if ((exeverbosecount > 9) & gVerboseMode) { pause(); exeverbosecount = 0; } exeverbosecount++; 对于启动过程中存在System uuid 不存在，fixing 00112233-4455-6677-8899-AABBCCDDEEFF的错误，这并不是导致卡waitting root device的根本原因。应该是硬件驱动不起来或驱动没识别。但是可以去掉这个错误： 在smbios.plist中加入以下： <key>SMsystemuuid</key> <string>88D1F108-02EE-3622-99CE-EA53BEA03BD9</string> 或Libsaio,smbios.c->uint8_t *fixSystemUUID()中修改 最后，sudo make clean，sudo make pkg或dist，得到新boot和cdboot 新installer镜像和tcpe，测试启动 对于4，虽然不能找到osx安装没有驱动部署过程的证据，但找到了一个新的简便办法制作installer镜像，发现osx下操作raw image也很方便(linux处理镜像之后的结果在osx的磁盘工具中结构视图是mixed一团的也不好看qemu-img convert -f dmg -O raw也不好用)，可以直接： dd if=/dev/zero of=osxkvm bs=512 count=52428800 diskutil partitionDisk disk3 MBR fat32 BOOT 100M JHFS+ OSXKVM R JHFS+ OSXKVMINSTALL 10G （installer本来8G就够，但需要手动替换1G的Extensions故10G，installer放最后可在安装完系统可磁盘工具把它合并到OSX，OSX留15G刚好总25G刚好也是轻量的磁盘大小） hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount osxkvm （仅attach,没有可装载的文件系统，一定要使用nomount） 挂载OSXKVMINSTALL,安装EasyMBR-Installer1013，不要安装变色龙bootloader,安装后，OSXKVMINSTALL会由日志式变成非日志式hfs fdisk -e /dev/rdisk3,flag 1,write,yes,quit。 （fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory 没事，略过） 然后整个卸载回到linux装grub2,memdisk和tinycorelinuxpe （sudo deepin-editor grub2.cfg，删掉所有内容，只保留二段menuentry，和一个全局set timeout久一点）。 在这里，你还可以制作一个带mount hfsplus免linux中关闭hfs+ journal内核（>3.4）的新tinycorelinuxpe。tc7是4.2的kernel，也有一个hfyprog.tcz(仅限x86)，进64bit deepin15编译32bit kernel里，gcc -v是630版，从http://mirrors.163.com/tinycorelinux/7.x/x86/release/src/kernel/Wget linux-4.2.9-patched.tar.xz和config-4.2.9-tinycore，sudo apt-get install gcc-multilib g++-multilib module-assistant libncurses5-dev libncursesw5-dev genisoimage( genisoimage 已取代之前的 mkisofs ）,cd linux src根，Make mrproper,make menuconfig,加载config-4.2.9-tinycore,加上virtio(按/查找virtio，发现有virtio_blk,virtio_net,virtio_pci),再集成hfs文件系统(/查找hfs,发现hfs_fs,hfsplus_fs和hfsplus_fs_posix_acl)，save成.config，再额外打个防vmlinuz启动时出现“failed to allocate space for phdrs system halted”的bug补丁（见https://bugzilla.kernel.org/show_bug.cgi?id=114671t和https://bugzilla.kernel.org/attachment.cgi?id=209601&action=diffr按这个手动改下源码） 之后就可以make bzImage了，cp to vmlinuz,用http://mirrors.163.com/tinycorelinux/7.x/x86/release/distribution_files/core.gz和它组成新的virtiope,然后制作iso:把tc7的isolinux提取出来，cd tcpe,sudo genisoimage -R -J -T -v --no-emul-boot --boot-load-size 4 --boot-info-table -V "tcpe" -b isolinux/isolinux.bin -c isolinux/boot.cat -o ../tcpe.iso . (genisoimage很奇葩，-b 和 -c里面不能写绝对路径，应该写的是相对iso的相对路径，否则找不到boot catalog) grub2也可直chainloader boot0，比如fat32装变色龙dd if=/dev/rdisk1s2 count=1,bs=512 of=origbs,cp boot1f32 newbs,dd if=origbs of=newbs skip=3 seek=3 bs=1 count=87 conv=notrunc,dd if=newbs of=/dev/rdisk1s2 count=1 bs=512，menuentry写insmod hfsplus,set root='(hd0,3)’,search --no-floppy --fs-uuid --set beec0ed4-a131-3ad3-9406-35cd8ebfb1b4,parttool (hd0,3) boot+,chainloader (hd0,1)/boot/chameleon/boot0,blkid显示uuid或tune2fs -U c1b9d5a2-f162-11cf-9ece-0020afc76f16 /dev/sda5更改uuid，有些电脑不支持 grub2下uuid的搜索，会Error：no such device:3c7c1d30-86c7-4ea3-ac16-30d6b0371b02，不过我们还是使用自己的grub2+memdisk+iso方案(iso中的文件系统是个hfs+,en0 0，它并不是fat32)。 镜像做好虚拟机可以直接用，上传到云机，installnet.sh如果https你要支持https，要wget --no-check-certificate，轻量的vnc后台窗口如需滚动窗口，请将鼠标移动到窗口左右两侧空白处，再进行滚动操作。。 现在要启动了，org.chameleon.Boot.plist几乎是总控文件，所有参数都在这里，kernel.plist,kext.plist只是patchs定义（注意KernelBooterExtensionsPatch to load extra kexts besides kernelcache），Themes文件夹和gui相关就不要加了。Extras/Extensions中不要加fakesmc，因为被enoch内置了，如果你碰到，ebios error，Startup error pause 5s,一般都是不正确kext导致的。 重点的org.chameleon.Boot.plist中的启动参数: <key>Instant Menu</key> <string>Yes</string> <key>Default Partition</key> <string>hd(0,3)</string> <key>Timeout</key> <string>10</string> <key>Kernel</key> <string>kernel</string> <key>CsrActiveConfig</key> <string>103</string> <key>UseKernelCache</key> <string>Yes</string> <key>Kernel Flags</key> <string>darkwake=0 npci=0x3000 debug=0x100</string> 同时kernel flags千W不要加-v，也不要加-f，毕竟这些都可以启动时按任意键手动加，也是后期调试必须手动敲入喂给kernel的部分。加debug=0x100（Don't reboot on panic，pause），但千W不要加wait加了wait=yes会黑屏，至于其它参数也是手动加的不要加进文件内（“-F”可以忽略org.chameleon.Boot.plist中的kernel flags）： "-x" 安全模式，载入最少的kext。which ignores all cached driver files."-f" (默认是 No) Lion 专用，选用 Yes 将载入预链接的 KernelCache，并忽略 /Extra/Extensions 和 /System/Library/Extensions 及 Extensions.mkext。建议在 KernelCache 已内含所有必要的驱动时，才启用。使用 (-s) 单用户模式进入，可于在开机进入命令模式排除问题。也许bdmsg就是在这里用的，不过这仅限能启动进入console kernel 基本上，解决和完成了问题1，2，3，到这里，变色龙级别的启动是可以无阻进行的，出现问题的，大部分都是darwin kernel启动之后出现的，像上面提到的waitting root device。我们把变色龙的启动和kernel的启动分开，前面讲到的都是变色龙的，这里开始我们讲kernel的启动，，After the KEXTs decompression phase, you should see the kernel booting ，TMSafetynet.kext 是最后一个,之后便会starting Darwin kernel（它本来进入显卡的图像模式，应该换一个分辨率显示文字，）。启动文字在虚拟机上花屏变色（正常是白色），最后IOConsoleUsers: time(0) 0->0, lin 0, llk 1, IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0, nov 0, sm 0x0错误无法继续，然后apfs module stop，在云主机上黑屏，无后续，免v下，虚拟机图形有进度条，云机无。 看来，即使是这样，虚拟机跟云主机也不是一一对应的，云主机属于一个更小的集合。qemu机->qemu guest机->qemu云主机就像同显卡qemu方案云主机会黑屏虚机不会。 驱动，以及影响启动的综合未完成问题 对于问题5，前面说的黑屏，卡住都是驱动问题（gIOScreenLockState错误原因是系统无法识别出你的显卡驱动,所以这个黑屏，是kernel的问题，不是变色龙的。），是1014不含这些驱动吗？而且10.14包含virtio,virtgraphics这些云机驱动（只是我们可能作很多黑果方面的工作使它工作：识别和驱动，在前面，我们按EasyMBR-Installer1013脚本A5,A6做的工作也把virtio,virtgraphic这些驱动做到S/L/E中去了，SLE:system,library,extensions）。 所以这问题大了去了，（为什么我们执着于10.14，14较新icloudrive支持高我们黑果的目的主要就是这，10.10-10.15的UI是一系的不排除内部实现有版本大更），我们从综合高度来思考这类问题： 硬件与bios与boot与os包含：QEMU uses the PC BIOS from the Seabios project and the Plex86/Bochs LGPL VGA，Seabios与qemu绑定bundle SeaBIOS 1.9.4 binaries with QEMU v2.7.1，就是变色龙no gui启动时显示的那个qemu，由qemu仿真的cirrus VGA就是一种典型的SVGAhttps://www.kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display/，https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/.但是云主机lspci -vnn | grep VGA，虚拟是的是一块Cirrus Logic GD5446，为1996年pci vga的显卡VBE 2.00(VESA BIOS EXTENSION)，显存2-4mb(云机的bios是什么版本?)。Mojave ships with a driver for qemu stdvga and qemu cirrus vgahttps://www.kraxel.org/blog/2019/06/macos-qemu-guest/.osx从Yosemite开始不支持VGA,从skylake平台开始砍了原生vga通道，最新的Mac电脑都是没有VGA接口的，所以苹果的驱动里面理所当然就没有VGA接口的描述信息，macOS Mojave 10.14.x开始不支持NVIDIA显卡,苹果早就把 Mac下 Intel核显驱动 中 vga接口代码 全部移除了,最惹人注意的就是A卡的一堆、hd3000的几个、N卡的几个加上高通的无线网卡驱动，(没驱动的时候，vga有画面，只要驱动就黑屏。集显DVI没有问题，集显vga有问题)对于已有驱动，如AppleHDA.kext，Apple也已从其中删除了大量的Layouts，苹果就是这样一个追新弃旧派。 驱动工作模式与os支持：vga兼容模式一般是显卡在刚开始启动系统还没有加载显示驱动的时候，ramfb is a very simple framebuffer display device. It is intended to be configured by the firmware and used as boot framebuffer, until the guest OS loads a real GPU driver.If your guest OS supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if you want to use high resolution modes (>=1280x1024x16) then you should use this option.对于linux：You have two Cirrus graphic options in the kernel, CONFIG_DRM_CIRRUS_QEMU is the KMS framebuffer that fit with qemu-kvm with a Cirrus virtual video card. The help say that it's only appropriate for virtualisation with the use of the modesetting Xorg video driver. So here, the use of the cirrus Xorg video driver is not what they recommand. You have also the CONFIG_FB_CIRRUS option that is a framebuffer driver for real Cirrus graphic cards. This framebuffer driver support the Qemu Cirrus emulated graphic card, but only tests can say fi it work with. 对于osx：https://www.kraxel.org/blog/2019/06/macos-qemu-guest/中提到virtualgraphics.kext也有Cirrus framebuffer，但并没有深入讲。这有可能是个efi驱动,那个simple osx kvm仓库中*.fd的补丁，就是OVMF（UEFI对qemu的实现）,Note that OVMF has a Display Resolution Setting too.那个virtio blk可能也是。 boot与os的关系：我们知道，能启动osx是qemu+firmware/boot(grub,chameleon)+硬件+osx的合力效果,grub有grub的文件，osx有osx的文件，变色龙有变色龙的文件，grub2与变色龙都属于osx前面一级的boot，这里grub2+wow.pc变色龙，grub2只负责boot，没有 firmware的作用，对于linux它有，比如它传给kernel的参数（这种关系就像变色龙之于osx），对于osx没有，我们发现grub2的mods很多与变色龙相同，而且用memdisk启动，存在依赖关系。会模拟出一个en(0,0)，Grub2和变色龙，也都可以在boot级就改变显示模式和效果。共享同样的boot技术。比如GRUB2也有insmod vga,insmod video_cirrus，it uses VESA BIOS Extensions to display the boot menu with enhanced resolution (and color depth), 当变色龙加osx出现Rooting via boot-uuid from xxx,Waiting on ioproviderclass时我们看到也提示了uuid，跟grub2一样no such device。结合前面《linux as boot》我们讲了linuxboot和一个集成开发层到boot的东西，这样os下来就全是这种语言的app，甚至不必处理驱动硬件，python能在bootloader运行无须os也是一个例子BIOS Implementation Test Suite(BITS)。可以看出：其实boot就是firmware，它作为boot的意义是很浅一部分，驱动硬件，才是最主要的。 对于问题6，不能，理由无 ———————— 对于现在的问题，virtio不能在云机osx驱动，虚机cirrus-vga花屏云机黑屏，有没有继续的必要？苹果的驱动里面没有VGA（但不是不可以从别处找到用于Intel GPU的VGA接口的代码，甚至第三方）Apple也已从其中删除了大量的信息，（但修改Injector这些kext修补缺失部分可以设备正常工作。）甚至修改dsdt，edid注入 —— 所以还是值得试下。 下文将力求解决显卡和硬盘驱动问题，真正实现云上黑果。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践（4）：阿里轻量机上变色龙bootloader启动问题
本文关键字：处理云主机上大镜像安装问题，编译 enoch 变色龙 在《云机装黑果实践系列》1-3中，我们完成了直到生成镜像的所有准备工作，现在要上机测试了，进入最困难的boot-机型适配调试了，这也是黑果技术最典型的实践密集点，结合搜索引擎从最最小依赖一点一点添加配置是唯一的流程（基本上，变色龙是appleboot+fake efi as bios发展来的，具体机型千千W，云主机又特点，这种适配和调试工作变数和坑很多），我选的是一台阿里云轻量云主机，第一步是把镜像传上去。对于一个7G展开20G的打包镜像，moeclub的installnet.sh其内部使用的是wget gunzip输出到stdout再dd的管道，gzip版本太低，解压到前面很少一部分就会hang，脚本自动重启，找到那句将其改成wget -qO- '$DDURL' |tar zOx |/bin/dd of=\$(list-devices disk |head -n1);Tar 不要加f和其它参数,版本不够。正常边untar边dd在我这（港区oss与轻量）要50来分钟，镜像正常启动grub2,进入tinycorelinux virtiope，fdisk /dev/vda，p显出正常hfs+分区，或者直接grub2 insmod hfs hfsplus part_apple，ls (hd0,msdos2)/ 也可以看到osx分区上的文件。之后迅速做一个快照，以防接下来的调试破坏系统。 如果说上面解决installnet.sh的脚本问题是小问题，那么大boss来了，r2922的cdboot在实机和kvmqemu机上可以运行，在云主机上根本无法运行（grub2进进入tinycorelinux virtiope，sudo mount /dev/vda1,sudo wget生成的iso，重启进入），不能显示引导界面，也是自动重启。(除了cdboot,按教程直接boot0h,hfs启动hfs分区的硬盘系统不行，用mbr+boot1f32也不行。) 问题可能在哪？这就是前面提到的ignore_msrs,我从memdisk版本问题开始排除，最后聚焦在boot本身上（cdboot这个stage2基本是一个boot+2560kib），猜想可能是版本问题导致的，利用排除法，先在网上海找了一通，能找到的最流行的低版本，就是v5.0.132 enoch r2839，，其cdboot写iso可以启动主机。最大r2841也可以，2842开始就不行。 翻看http://forge.voodooprojects.org/p/chameleon/source/changes/2842/，发现经过了三个commit，重点是源码上的变化: Commit 2842, by ErmaC : General updateCommit 2841, by Bungo : 1) Dropping DMAR (DMA Remapping table) to use stock AppleACPIplatform.kext - resolves stuck on "waitForSystemMapper" or "[PCI configuration begin]" 2) Added "ACPI" (all capitals) path 3) Small cosmeticsCommit 2840, by Bungo : Sync 剩下就是实际编译出cdboot判断问题到底出在哪个commit了 从enoch的源码中找出变化，实际编译 编译环境是pd上的xcode 8.2.1 for EL CAPTAN 10.11，这套配置可以编译2841->2922，其它的都会有问题。苹果的开发链都很封闭自由度不高。只能选择这个配置了。 下载一个10.11，把它作成pd能安装用的镜像，原理跟mbrpatch打包类似，适合在PD安装老版本osx使用。 (以下差不多任意版本都适用) hdiutil attach /Applications/Install\ macOS\ Sierra.app/Contents/SharedSupport/InstallESD.dmg -noverify -nobrowse -mountpoint /Volumes/install_app hdiutil create -o /tmp/Sierra.cdr -size 7316m -layout SPUD -fs HFS+J hdiutil attach /tmp/Sierra.cdr.dmg -noverify -nobrowse -mountpoint /Volumes/install_build asr restore -source /Volumes/install_app/BaseSystem.dmg -target /Volumes/install_build -noprompt -noverify -erase rm /Volumes/OS\ X\ Base\ System/System/Installation/Packages cp -rp /Volumes/install_app/Packages /Volumes/OS\ X\ Base\ System/System/Installation/ cp -rp /Volumes/install_app/BaseSystem.chunklist /Volumes/OS\ X\ Base\ System/BaseSystem.chunklist cp -rp /Volumes/install_app/BaseSystem.dmg /Volumes/OS\ X\ Base\ System/BaseSystem.dmg hdiutil detach /Volumes/install_app hdiutil detach /Volumes/OS\ X\ Base\ System/ hdiutil convert /tmp/Sierra.cdr.dmg -format UDTO -o /tmp/Sierra.iso 再https://developer.apple.com/download/more/下载Command_Line_Tools_macOS_10.11_for_Xcode_8.2.dmg装上。 最后下载源码：svn co -r 2841 http://forge.voodooprojects.org/svn/chameleon/trunk/，svn co -r 2842 http://forge.voodooprojects.org/svn/chameleon/trunk/，svn co -r 2922 http://forge.voodooprojects.org/svn/chameleon/trunk/ 它们的编译都是cd trunk，然后直接make，经过几次尝试，从最初直接替换libsaio/cpu.c,cpu.h,platform.c,platform.h，到最后仅在2842 src中libsaio/cpu.c找到以下二句并注释掉 // case CPUID_MODEL_SKYLAKE_AVX: // case CPUID_MODEL_CANNONLAKE: Re make clean Re make 其产出的cdboot都是可以用在云主机上作正常启动的。这也可以被用在2922上。 再一步步调试出能启动云主机的变色龙配置： 到现在为止，终于进入对类似现实机器调试变色龙的流程来处理针对云主机安变色龙的问题了，这就是在上述一次次的“修改参数+打包iso+tinycorelinux上传”的循环（这也是我们当初使用grub2+memdisk的基本考虑）重复调试参数了：云主机较特别，可能会因为一个问题无法最终成功，但至少希望就在眼前。因为我们解决了大量关键问题。 注：碰到上传了正确的cdboot打包的iso，也启不动云主机到界面的问题，但有一个workarouds：2841和2922的wowpc.iso都上传，发现2922不能启动到界面，先启次一次2841，之后2922总可以成功。猜是loader改变了相关mbr参数，是残留的硬件作用。启动一次2841可以将其复位。（或许整个替换cpu和platform编译会根本解决） 最小配置是这样的： org.chamalon.boot.plist <key>Kernel Flags</key> <string>-v -f</string> <key>Timeout</key> <string>30</string> 下文继续详解。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践（3）:得到云主机安装镜像
本文关键字：qemu kvm mojave enoch，，grub4dos 手动mbr安装到fat32，linux 挂载多区段镜像分区 前面二文讲解了在kvm/qemu上尝试安装osx的工作，基本上，变色龙，四叶草，opencore的使用，就是在具体平台上尝试不同的patch参数(acpi,dsdt,etc)和大量第三方kexts，调试是最主要的工作，这三个loader支持都不相同，最弱的是变色龙，只是变色龙的mbr支持是最简单的和云机友好的。那么，作为一类特殊硬件，在云主机上主机启动遇到问题，该如何调试呢。又有哪些特殊呢？第一步是创建出云主机能用的镜像，上传测试。 前文我们使用的是PD开nested虚拟化实现了安装mbr patched 10.15。接前面的测试环境，我们继续来讲解。为了简化工作，我们要在deepin linux上事先创建这个镜像并处理，用raw格式而不是qcow2，得到的raw我们可以直接打包供InstallNET.sh用，我们这次选用的是10.14，因为10.15镜像有点大，而且我们尽量在linux下完成大部分工作 ——— 在osx recovery上分区很麻烦。 为了更方便调试引导区，我们要设置一个200m的引导区，并加入grub2和virtiope，然后chainloader变色龙iso。 —— 变色龙直接作为第一层引导好像在云主机硬盘上会有启动问题。 制作镜像结构和启动 在《离线编辑skynas镜像》文中我们讲过挂载一个多区段的镜像，但是现在我们是从0开始的镜像,是空盘和空分区，不是一个导出的有结构的镜像，我们采用20G，10.14安装后约有11-12G，云硬盘最小也是20G： qemu-img create -f raw osxkvm 20G(或dd if=/dev/zero of=osxkvm bs=1024 count=20971520) 我们现在可以通过fdisk osxkvm, mkfs.vfat osxkvm直接操作这个镜像。使之有mbr和分区信息。但是注意：这是针对常规盘已有设备挂载点的（整盘已被挂载）那些操作，这里的镜像文件，虽然内部有分区信息（但没有被挂载），所以分区也得不到挂载设备点，不能经过格式化获得文件系统信息，也就不能实现挂到文件系统。 对于空白镜像，我们可以通过loop将整盘镜像虚拟成块，统一完成分区和格式化/挂载这样的工作： losetup -fP --show osxkvm (P参数是带分区的镜像，show参数可以查看刚losetup到的盘，省掉一次losetup -a) fdisk /dev/loop0进去分区,会自动转为mbr和msdos,n一个2048起的+200M分区，并a为活动，这就是我们的启动设定盘，其余空间作为一个分区，设置卷标BOOT,OSXKVM(注意不要生成在PD的/media/psf/xxx，否则打不开, 始终要注意，镜像文件的不同步,这时你要重启deepin。或者将镜像移到deepin里面) 现在才可以格式化和挂载分区： mkfs.vfat /dev/loop0p1 mount /dev/loop0p1 /osxkvm1（下回再挂载分区就是《离线编辑skynas镜像》文中的-o offsetnumber mount了） 好了，我们现在给它安装启动，我们不会直接在fat32里mbr装变色龙（原因：启动分区是调试必要的，云主机硬盘直接单分区hfs+启不动，4k硬盘装变色龙也有变数,变色龙装在fat32也有特殊：不能直接dd boot1f32，要把原pbr备份下来整个写入新的，再恢复部分老的，dd if=opbr of=/dev/rdisk1s1 bs=1 count=86 skip=3，dd if=opbr of=/dev/rdisk1s1 bs=1 count=90 skip=422 ）： 所以为了省事我们用grub2引导wowpc.iso这些原来在windows下用的： grub-install --boot-directory=/bootpart /dev/loop0grub-mkconfig -o /osxkvm1/grub/grub.cfg(这里/dev/loop0为虚拟块对应设备，/bootpart为fat32启动分区的挂载点,deepin的grub.cfg有延时设置不用update-grub) 为wowpc定制grub.cfg,加个menuentry "chameleon”，这里的wowpc.iso在接下来一节要准备好： set root='(hd0,msdos1)’linux16 /syslinux/memdisk iso raw(记得在系统内apt-get install syslinux拷相关文件到boot：cp -av /usr/lib/syslinux/ /bootpart/syslinux)initrd16 /wowpc.iso 把boot-macOS.sh去掉cdr发现这个raw image是可以grub2启动的,你还可以定制grub逻辑，加入tinycorelinuxpe。接下来就是制作镜像主体：那个osxkvm分区，和wowpc.iso引导文件了 Recovery里安装OS X得到镜像文件和引导 跟据上文，准备mbr patched 10.14 install.cdr（提一下，替换A5,A6会出现apfs stop），全程记得用https://github.com/chris1111/Chameleon-macOS-Mojave-USB/releases/tag/V2 chris1111的安装包ChameleonEnochv2.4svnr2922-Post.pkg在EasyMBR-Installer1013.sh脚本完全后写入，不要用其它地方来的。 ps: 自定chris1111的配置： FakeSMC-Extra-Options->FakeSMC-NULCPU->FakeSMC&HWMonitor:HWsensors.V6.26.146，安装FakeSMC,安装(Fakesmc是为把boot-macOS.sh中的device smc参数消减，所以接将kexts做进osx来解决，必备黑果驱动)CPUSensors,GPUSensors,LPCSensors都取消FakeSMC-Extra-Options->Extra-smbios:Extr,安装SMBIOS PC on Laptop->imac14,2，勾选跳到最后Chameleon Enoch v2.4svn r2922->Chameleon Standard勾选standard mode安装变色龙引导到虚拟U盘，，它默认以-Xmpc -v等参数启动。删掉主题default后启动会更清爽。 在osx下虚拟U盘复制以下引号里提到的文件到某一目录，准备制作wowpc.iso，并把它放到虚拟U盘Extra下 sudo hdiutil makehybrid -o wowpc.iso “boot,Extra,Extra/extesions等chris1111的变色龙引导配置文件所在目录”/ -iso -hfs -joliet -eltorito-boot “虚拟U盘standalone/i386/cdboot”/cdboot -no-emul-boot -hfs-volume-name "Chameleon" -joliet-volume-name "Chameleo" -iso-volume-name "Chameleo" cdr和wowpc.iso准备好了，启动boot-macOS.sh进入recovery,如果启动有问题，加-f重建缓存启动， 在recovery里界面的磁盘工具中查看未分区的盘号，这里是disk1s2，发现不是很好看，二个区凑一起了，但是没关系，能用就行(要得到好看的，diskutil partitiondisk disk1 MBR fat32 “BOOT” 200M HFS+ “OSXKVM” R，在linux里按上面过程返工吧), 退出磁盘工具进入命令行，打入：sudo diskutil eraseVolume JHFS+ OSXKVM disk1s2 拷wowed.iso到boot分区根下：cp /Extra/wowpc.iso /Volumes/BOOT/ 进入安装界面,开始安装OSX到上一步准备的镜像osxkvm，因为是在PD中是虚拟套虚拟，安装性能有点慢，安装接近完全，最后一分钟要等好久,把最后得到的osxkvm测试启动，最后关掉PD，把得到的raw image gzip -c xx>xx.gz打包，完工！。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践（2）：在deepin kvm下测试mbr方式安装的黑果10.15最新版
本文关键字：QEMU 免kernel firmware运行黑osx，把enoch做进iso normal boot,建立10.15 enoch懒人安装包 在前面云主机装黑果系列文章中，我们知道了变色龙Chameleon,四叶草clover作为黑果技术的本质，其原理就是重写了白苹果的引导。但它们不是一般的1）boot to os loader，而且也是2）firmware to os(fake devices, inject kexts，patch to kernels,配置tricks) ，即firmware as loader，黑果的技术基础就是依靠它们将kexts和配置写入安装包或系统运行时的内存代替官方,操作起来复杂度不低，因为它们都是为不同硬件写的，所以大量第三方kexts的注入选择，硬件平台适配和osx版本对应是一个考究，集成大量kexts可能使一台PC上的黑果”负重“（采用了过多的固件驱动），所以这类固件也不要在白果上用，可能损坏硬件，最有可能损坏的就是视网膜屏，绝非危言耸听。 它们都同时支持bios(mbr,mbr+gpt)和uefi（gpt）,可以启动windows,linux但又都对osx专门做了工作,都有相关工具，如gui wizard tools。但一般来说，clover更灵活更强大,支持更新。《实践（1）》文前面我们是实现了装在本地kvmguest上，使用了Chameleon。好了，我们继续讨论用它让黑果装在云上，阿里云云主机一般是qemu standard i440fx pii(x3)老intel机型，Xeon E5-2682 v4 以上cpu，bios机(如seabios8c24b4c)没有uefi，只能从mbr上启动，而且驱动部分是virtio。所幸硬件上这完全可以运行黑果最新版，经过一些破解，软件上也完全可以，我们要做的工作就是，将前文章第二部分启动脚本里的enoch做的固件和引导(包括支持某osx版本安装运行所有做的全部破解工作)的工作集成到osx内部/guest vm内部： 首先是那个显而易见的大问题：bios云主机是不能以外部喂给kernel的方式提供firmware的，那么enoch能不能像普通boot如grub那样，集成firmware到os镜像内呢，这是可以的，因为变色龙是一种firmware as bootloader，我们在grub2的命仅行下也能浏览文件，这里的loader本该是os的功能但居然可以共存，loader就是第一层os，linux是第二层os，可以前后启动，变色化也可以是一种grub2 loader，被安装在硬盘上且充当osx的传手，一前一后启动，—— 这就是说，mbr和bios机，也支持将一部分firmware放在硬盘上与os一起（就如同efi文件夹与os一样）。 不管如何，让我们实践吧，这次我们直接测试10.15。因为这次我发现PD居然有嵌套虚拟化，这次我们在OSX+PD虚拟机DEEPIN测试黑果,不用跟上文一样重启来重启去了。 1）让qemu免kernel在kvm guest主机上运行黑果 工作依然是建立新的可启动iso开始。(最终我们要得到一份能InstallNET.sh用在云主机的安装后的磁盘image dd)，但是我们需要在kvm/qemu上测试一下，所以还是按常规流程做成iso。因为10.15比前文osx-kvm脚本中的createinstalliso.sh提到的10,11,12,13更高，较10.11，12，事情有了不同：10.14开始，osx强制运行在uefi和apfs上，做了这方面的硬性选择，我们需要破解其为mbr和安装在普通hfs+上。能找到的开始支持10.15的引导是enoch2921 https://www.insanelymac.com/forum/files/file/71-enoch/。—— Crazybirdy有一个仓库和脚本专门https://www.insanelymac.com/forum/files/file/985-catalina-mbr-hfs-firmware-check-patch/解决这二大问题，搜索Catalina MBR HFS Firmware Check Patch 10.15.x可到。下载，里面有一个MBR-Manual-Method15-20191209.dmg，解包打包成MBR-Manual-Method15-20191209.zip本地存储。还有一个enoch2922有几个配置文件，也下载。 研究里面的EasyMBR-Installer1015和说明文件，提到破解了让安装程序不作mbr和convert to apfs方面的检查，重点是脚本中的打包iso逻辑（Work on 10.15.txt What's the difference between createinstallmedia method, MBR-Manual-Method, and MBR-Automatic-Method?），使用上拖入一个大于10G的安装U盘分区和一个install 10.15.app就可以，内部逻辑上，它其实跟前文osx-kvm创造iso的逻辑差不多：都是提取安装包install xxx.app中的basesystem.dmg（这是安装程序，recovery），对kernel进行补丁，kexts注入，Extra写入，将install xxx.app本体写入（因为对kernel有patch和kexts注入，对标准createinstallmedia逻辑流程有侵入，所以并不同于供vmware+unlocker虚拟机用的，用写入到虚拟镜像盘或U盘的方式，然后createinstallmedia形成一个新的懒人cdr的方式。），最终生成一个cdr。 但是，1）这个脚本都设想enchos是外置的，引导本身并没有写进去，因为脚本作者都是设想这类脚本生成的镜像是供在osx下使用和u盘安装使用的，最后，变色龙引导以post install方式被安装，—— 这也就是为什么enchos文件crazybirdy也是分开放的，也是Enoch-rev.2922.pkg这类发行打包方式使然，，只有osx能option识别这类方式制作的“可启动”U盘。只有先运行enoch作为固件或loader才能识别其中写入的安装（本身并不包括enoch）。2）问题2，整个cdr也不是一个标准的可启动的iso（放到windows下或qemu -boot d -cdrom './install.iso.cdr’ -m 512M 是不能启动的），因为本质上，这个cdr是dmg转换过来的,在osx和qemu+ kernel enoch机眼中，是可启动硬盘，而不是可启动iso 好了，我们现在要把EasyMBR-Installer1015里的脚本改造成生成镜像供qemu免kernel参数用上mbr patched了的10.15cdr，而不仅是U盘和实体机，最好是windows下也能用的bootable iso。。未来还要考虑云主机的接受方式。 2)变色龙mbr启动iso制作，在osx上制作变色龙mbr启动iso。将kernel集成到iso内部。 在2.4前变色龙是wowpc.iso发布的。但是r2922发布的是一个在osx上运行的“事后”package(追随clover系列风格)，离线安装到本地需要破解的黑果镜像或U盘。wowpc.iso里的boot加kexts加plist,后者gui方式需要手动选择大量项目（其实也不多）注意这并不是Chameleon wizard工具。 先创建一个虚拟U盘，供脚本使用。JHFS+即MacOS扩展（日志式），第一行创建的-fs是临时的，因为马上要在第3行重分区，第二行挂载，第三行分区为mbr盘中的一个hhfs+区要求10G大小保险，整个镜像11G，注意，去磁盘工具中查看dev node，我这里是disk3： hdiutil create -o “install" -size 11g -layout SPUD -fs HFS+Jhdiutil attach "install.dmg" -noverify -mountpoint /Volumes/install_builddiskutil partitionDisk disk3 MBR JHFS+ Recovery 10G 未来这个recovery区即是脚本执行时要用的虚拟U盘。打开它。 然后安装r2922引导，用Pacifist打开Enoch-rev.2922.pkg提取其中的Core.pkg中的所有enoch引导文件到一个临时文件夹，cd到这个文件夹的/usr/standalone/i386下，1)首先Install boot0 to the MBR（我们这里是为硬盘生成引导，如果是要作成windows下的iso：用hdiutil makehybrid -o mywowpc.iso 从wowpc中或Enoch-rev.2922.pkg/Core.pkg解压出来的所有文件加你的Extra配置组成的所在文件夹/ -iso -hfs -joliet -eltorito-boot 从wowpc中或Enoch-rev.2922.pkg/Core.pkg解压出来的所有文件加你的Extra配置组成的所在文件夹/usr/standalone/i386/cdboot -no-emul-boot -hfs-volume-name "Chameleon" -joliet-volume-name "Chameleo" -iso-volume-name "Chameleo”），2)然后Install boot1h to the partition’s bootsector到disk3s1(boot1h为for hfs+,boot1f32为for fat32,boot1fx为for exfat，如果用这个虚拟U盘生成的cdr启动时提示Boot0 done,boot1 error，那就是boot1文件选错了)，3)最后Install boot to the partition’s root directory: sudo fdisk -f boot0 -u -y /dev/rdisk3 sudo dd if=boot1h of=/dev/rdisk3s1 sudo cp boot /Volumes/Recovery 你还要把crazybirdy里面推荐的Extra配置文件复制到打开的虚拟U盘(这个U盘是可写挂载的)。 最后，打开EasyMBR-Installer1015编辑（这个盘跟脚本里的U盘实体属性有一点是不等的，比如它不能动态erase，故）： diskutil eraseVolume JHFS+ Disk1mbrJHFS ${devDisk1mbrInstaller} 从这里开始改 diskutil rename "${devDisk1mbrInstaller}" "Disk1mbrJHFS"echo "rename virtual disk to disk1mbrJHFS done" 运行脚本后，选择我们准备的install 10.15.app和虚拟U盘拖入，运行到成功结束(中间会有lzvn需要放行。但脚本也不会等待，直接复制失败，所以放行后再次运行脚本从头建立虚拟U盘生成即可。)，它进行了mbr10.15黑果上前述脚本处理引导破解和firmware注入的工作（A1-A4），如果需要，你需要在镜像制作完成后额外手动完成以下动作还要二步： A5. (Needn't with Clover, Need only if you use Chameleon with -f to boot Disk1mbrInstaller, use Pacifist v3.2.14+ to access Core.pkg.) Make directory of /Volumes/Disk1mbrInstaller/System/Library/Kernels first. Copy InstallESD.dmg/Packages/Core.pkg/System/Library/Kernels/kernel to /Volumes/Disk1mbrInstaller/System/Library/Kernels/kernel A6. (Needn't with Clover, Need only if you use Chameleon with -f to boot Disk1mbrInstaller, use Pacifist v3.2.14+ to access Core.pkg.) Replace InstallESD.dmg/Packages/Core.pkg/System/Library/Extensions to /Volumes/Disk1mbrInstaller/System/Library/Extensions 这样，这个虚拟U盘就成为mbr patched,（注意它并不是脚本运行后要安装到的“系统目标盘”），等脚本完成，将其转成iso，${mbrdiskname}是脚本中的名字，实际名字会是Volumes/10153EasyMBR19D76之类： hdiutil detach "/Volumes/${mbrdiskname}" hdiutil convert “install.dmg" -format UDTO -o “install“ 现在可以执行上文中的Boot-macOS.sh了，进入PD中的qemu-kvm，，这次，可以免kernel参数了，修改脚本删掉，内含enoch启动，它会自动找到分区中的installmedia： 以后，你完全可以re Detach re convert来重新修改dmg和生成新iso来解决启动中出现的问题或深度定制你的黑果。 ——— 其实黑果上登icloud也不会被封，如果你实在不放心，买个100元不到的iphone4，硬件上也登着。恩恩 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
Linuxboot:linux as UEFI,linux over UEFI
本文关键字：linux as UEFI，linux over UEFI，qube-os 在前面《将虚拟机集成在BIOS和EFI层，硬件融合的新起点：虚拟firmware，avatt的编译》及前面一些关于coreboot的文章中，我们提到coreboot是一种开源的boot+firmware，它是从硬件加载到firmware（能够存在于flash的其它非hardware initial必要部分）全包的，coreboot聪明地分开了这二者，将firmware部分视为payload。我们还提到coreboot最初的payload就是linux，除此之外，它还支持UEFI，任何可以在硬件加载完后可执行的东西。 这就是说，coreboot的硬件加载部分依然是需要自实现的。面对一块新主板新平台，开发上，除了软件部分（可以用QEMU调试），硬件上它要求刷机有时甚至要求烧录和焊接技能。—— 这对大部分工作来说都是很麻烦的，写好了也不便于安装。 而UEFI是一种开放的firmware标准（虽然大部分UEFI是闭源的），而且适用于现大部分INTEL平台，为了在平台上开发使用UEFI，照样需要完成硬件加载和firmware衔接工作，和重点的fimware编写工作（DXE），TianoCore是一种开源的UEFI，coreboot的硬件加载部分可以结合tinacore使用。视TianoCore为payload。—— 虽然还是有很多工作，不过，在这种方案下，coreboot的硬件加载可以直接采用该平台开放的部分，然后接入自己的UEFI逻辑，而intel vendor UEFI firmware平台随处可见，是用户可得的。 那么对于我们追求的Linux as firmware，有没有一种更干净的连接起硬件加载部分和firmware的机制呢？并在UEFI上使用 LINUX的技术呢？ 这就是linux as UEFI或linux over UEFI。Linuxboot就是这类技术实现的代表 LINUX BOOT The LinuxBoot project https://github.com/linuxboot/linuxboot (formerly NERF) is a collaboration between Google, Facebook, Horizon Computing Solutions, and Two Sigma that aims to build an open, customizable, and slightly more secure firmware for server machines based on Linux. It supports different runtimes, like the Heads firmware or Google's NERF. Unlike coreboot, LinuxBoot doesn't attempt to replace the chipset initialization code with opensource. Instead it retains the vendor PEI (Pre-EFI environment) code as well as the signed ACM (authenticated code modules) that Intel provides for establishing the TXT (trusted execution environment). The LinuxBoot firmware replaces the DXE (Driver Execution Environment) portion of UEFI with a few open source wrappers, the Linux Kernel and a flexible initrd based runtime. 1,它首先是一种UEFI实现，跟TianoCore一样，用来代替闭源驱动，相当于coreboot+uefi payload。不过它的工作比coreboot+uefi payload更少。2,由于它也是全包的解决方案,所以也是一种coreboot代替品，而且它面向使用linux这点与coreboot也不同，coreboot中并没有使用linux当uefi的部分。3,linuxboot+runtime可以采用cb的硬件加载，也可以使用自己的硬件加载，其linux kernel部分是不变的。4,它可以实现在硬盘的UEFI分区上直接置换firmware。这样至少对于安装是很方便的。5,以上其实最终实际上也符合我们在《将虚拟机集成在BIOS和EFI层，硬件融合的新起点：虚拟firmware，avatt的编译》文提到的理论基础，即：linux本身与UEFI技术中的驱动本来就存在重复工作，所以wrapper一下得到的结果也能很好融入UEFI。而linux作为开机预加载环境，可以实现kexec直接加载linux（kernel inside bootloader，不需要专门的bootloader），如果在其中加入虚拟机管理器，可以实现前述我们提到的并启和多OS运行。甚至，虚拟化firmware，可以让黑苹果，黑ios这样的东西变得现实 ——— 这些我们前面都有例子。 Linux boot唯一需要你定制和附加的，就是initrd制作部分，也就是它要接入的runtime，vs Coreboot and Coreboot payload，linuxboot将定制firmware的工作压缩到了仅需要定制rootfs的程度。 Linux boot runtime Linux boot支持Coreboot runtime（采用其硬件加载部分），linuxboot其前身NERF也是一种runtime，不过像coreboot一样，linuxboot发展到了支持多种其它runtime。如除了coreboot，还有Heads firmware，https://github.com/osresearch/heads 还有这里提到的，https://github.com/u-root/u-root u-root is an embeddable root file system intended to be placed in a flash device as part of the firmware image, along with a Linux kernel. Unlike most embedded root file systems, which consist of large binaries, u-root only has five: an init program and four Go compiler binaries. 基本上,u-root非常接近我们要得到的goblinux:go,busybox,linux as hyperisor inside boot, linux as user rootfs 。一份及早封装到上游的抽象打包linux for init programmers。 ————— 在linuxboot的runtime中集成虚拟机管理器，就得到了我们前面提到的并启虚拟化支持。Linuxboot它主要面向服务器主板作虚拟化。Qubes os就是另外一种主要面向PC主板虚拟化的。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
云主机装黑果实践（1）：deepin上qemu+kvm装黑果
本文关键字：用ubi在osx上打造一分区一安装启动U盘，deepin上qemu+kvm装黑果 在上文《云主机装黑果》中，我们讨论了其可能性，或许这里面的坑远远不止那文提到的，甚至最终不能成功。—— 但不管如何，实践总要先行。在理论与实践组成的一对学习矛盾中，先见独到的理论思考，与慢悠盲目的实践，都必不可少。现在让我们开始正式的实践。 我们在前面说到，现在最新的流行OS，如windows,ubt发行，osx，都是基于uefi机考虑的。同一个系统，安装在同一台pc的mbr或uefi模式下，表现结果和所需驱动都是不一样的，比如你会发现有些驱动不能工作而有些可以，有些都有驱动的表现也不尽相同，这是因为bios和uefi定义了同一硬件的不同规范。之所以再次提到这个，是因为继续云机装黑果前，我们需要制作一套实践环境。需要在PC上制作一套省事的，统一的osx,windows,linux多系统安装和启动法 ——— 这些同样与uefi相关： 我们知道，uefi提供了将固件放在磁盘上的方式（与OS同一处理方式），这带来的好处就是，所有的启动，不必再mbr式写启动动到磁盘结构了，也不必动到整盘，大家只需要在gpt的efi分区中写入uefi文件即可安装，也可运行，而且这对U盘硬盘，（写入安装）和（启动系统）都是一样的。在各OS运用不同磁盘格式的现实情况下，这也许是是在PC上u盘安装启动多系统的最省事方法。—— 但是历史上，有些os,如Windows uefi的安装程序不安分（会创造额外分区，msr,等等），osx uefi和deepin uefi之类的os倒是十分安分,苹果是支持installmedia 刻录到分区安装和启动的（你可能不知道，osx最初的标语是打造一个人性化的os，从note，日历，到icloud，个人认为日常都离不开这些，都是很人性的。所以就连它的createinstallmedia安装盘方式和本地盘方式也是基于分区的。），deepin也可以分区安装。这二者共存就是我们想要的结果：你会在一个装有多OS的GPT盘的efi分区发现多个系统的efi文件夹。至于windows，你可以pass使用它的安装程序，用winpe代替，集成wim安装包，pe里面会有一个nt6setup工具选择efi分区和系统分区的选项，从而达成我们要的结果。 1）用ubi在osx上打造一分区一安装启动U盘，一分区一系统的本地盘格局 下面介绍在osx下运用unetbootin677来制作这样的安装U盘的的方法：Unetbootin的特别之处在于它将安装镜像写入分区而不是整盘，有别于市面其它产品，原理就是syslinux+uefi+fat32，使用时选择镜像后对应分区要事先格式为fat32。但fat32的缺点就是一旦文件有超过4g。就不能使用ubi，但是dvd也有容量限制呢，所以这只是一种折中。 在osx的图形化磁盘工具中，我们将一个32gU盘分成3个10g(或osx 10g,deepin15 4g,windows 10 2019 ltsc 6g，10G作exfat data区放点其它东西 )，每一个分区写入一个安装iso，efi分区是自然生成的，，Ubi是不支持windows的仅支持linux，但是实测也可以按同样对linux的方式强行将windows pe带安装包wim iso刷入，至于安装到的本地多系统，我们也将本地盘分为三到四个区（osx留大一点，最后一个区可以是exfat data放点东西，我是256g,80g给osx,2x40分别给deepin15和windows,90g做data），这样，我们可以把OS X主系统下图形硬盘工具作出的这套结构作为主要的日常视图。日后在finder->位置->下看到清爽的磁盘结构结果,也方便我们接下来的工作（我们需要在这些系统间切来切去而不能使用pd虚拟机来完成以下测试）。 注意，只有osx系统才有开机按alt(option)显示U盘各分区的启动。也许未来在没有这种支持的电脑上也可实现，比如我们可以做个智能U盘，当某系统所属的分区需要被当前使用到，就设置一个把这个分区推出来的功能。来代替平果机的这种功能，而不用使用mbr统一菜单在分区间chain来chain去的那种。（除非某天所有系统都能安装到同一个分区使用同一种格式） 好了，下面继续我们的重点工作，在deepin15中安装qemu+kvm测试安装黑果。 2)deepin上qemu+kvm装黑果：准备工作 由于我的macbookpro是一台2015，cpu是支持虚拟化特性的，所以直接： Sudo apt-get updateSudo apt-get install virt-manager bridge-utils libvirt-clients qemu qemu-kvm 发现我的deepin-15.11-amd64在uefi下屏幕开机高亮的问题得到了解决，但是无线网卡没用，弄了个360usb wifi插好对付着用，发现下载到的qemu是2.81的。它的中心是一个libvirt加qemu，加一些类似管理机控制台的命令行和GUI工具，Qemu就是类似osx上bvyve一样的东西。后者也可以直接运行kernel。打开控制台，它里面有一系列虚拟的存储池，网络沲（配置文件和硬盘文件都在/var/lib/libvirt/image，/var/lib/libvirt/network/default.xml，/etc/libvirt/qemu/networks/default.xml)），你可以在GUI里新建一般复杂度配置的vm，但gui功能有限，更多更专业的参数需要命令行完成，如今天谈到的黑果。 根据前文《在阿里云上装黑苹果（1）：黑苹果基础 ，在阿里云上安装黑苹果（2）:本地虚拟机方案研究和可行资源参考》，https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/index_old.html和http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ 这二文基本是有关在kvm上装黑果的技术起源。后者都是别人基于这些研究的一些脚本工具集成。这二文中，old那文是直接用apple boot-132->变色龙(停更)->enoch对变色龙的修改，后来那文是正儿八经地统盘修改ovmf(更干净和接近uefi定制)，，再后来，别人就用clover这个更强大免编译的uefi来代替ovmf的编译了作出更简单的osxkvm方案（如https://www.kraxel.org/blog/2017/09/running-macos-as-guest-in-kvm/的kraxel和https://github.com/kholia/OSX-KVM的kholia）。 PS：Boot-132 is a bootloader provided by Apple for loading the XNU kernel，但是它并不用在真正的Mac上。而Chameleon is a Darwin/XNU boot loader based on Apple's boot-132.Enoch对变化龙的增强可以启动早期osx，甚至到10.11,10.12为止的osx，说到底，enoch与clover做的工作是一样的，也都是efi的，(但enoch是对seabios朝uefi的过渡层，与普通bios机和云主机的bios接近，云主机是seabios)，具体到kvm，enoch是kernel方式喂给qemu的,是bios上浅浅的一层。对Qemu/kvm guest方要求的更改最小，vs clover对uefi的要求最低。可能更适合我们未来将其用受限方式集成到受限的kvm环境如利用linuxboot等方式将其喂给普通阿里云ecs，以上是固件上的，其它工作方面，pc上黑平果的工作就像黑群，从loader着手，必要的时候，也重新打包安装包(vs synology upgrade pat)。因为这里要处理固件驱动注入，修改原包中正常启动参数到适合特定硬件启动，kvm guest机器其实可以类比通用pc上黑果技术的一组硬件特例处理,cloud kvm更是仅明确使用virtio驱动。 所以enoch这种，最接近pc黑果技术的起点，所以我们选择从它开始而不是clover 由于kholia在他的仓库中中把somlo的old文中的前期方案的相关脚本和工具也做了进来，所以这里为了方便我干脆采用它的一并说明，网上搜索kvmqemu osx出来的教程多用enoch_rev2839_boot和Install_OS_X_10.11.3_El_Capitan，所以这里也准备这样做。我clone到的2019.10.25的https://github.com/kholia/OSX-KVM/commit/64fcc1ef4d800197e8f4fc1421dd0f7060a72166，在整个脚本的backup文件夹内（backup之外的则对应最新利用clover的那些工具和脚本）。先看这个https://github.com/kholia/OSX-KVM/blob/master/notes.md，Enoch Bootloader (obsolete)是宣称过时的，意料之中，继续，1）脚本第一步，是create_install_iso.sh(for 10.11.0-10.11.4 and 10.12.0-10.12.5,只能在osx bash下运行)，它将从appstore下载到application/install OS X xxx app中的安装程序进行再打包，使之成为qemu适用的iso。如果你下载的OS X离线安装包，可以手动释放到application，这个过程中，一些必要的驱动和变动，也将被加进去，也就是破解kernel的方式。（这也是常见制作懒人包的方式 under pc黑果s），在安装过程中会用到。2）我下载到的是OS_X_10.11.3 El Capitan,运行，会出错，说tar 解压不到正确的格式包，下载安装Pacifist,用它打开install osx ei capitan.app/contents/sharesupport中的InstallESD.dmg，切换到”软件包内容”“资源”的“资源”，把Essentials.pkg释放到backup下，然后修改create_install.iso.sh中的对应处，成为python "$script_dir/parse_pbzx.py" "$script_dir/Payload" | cpio -idmu ./System/Library/Kernels || exit_with_error "Extraction of kernel failed”，重新运行脚本，得到Install_OS_X_10.11.3_El_Capitan.iso —— 与此同时，发现backup中，没有enoch_rev2839_boot，我从网上搜索下载到这个文件，放到backup中，值得注意的是网上下载到宣称2839的不一定就是对应版本.3）再在backup下创建一个40g硬盘，用来安装，qemu-img create -f qcow2 osxkvm.qcow2 40G。 3)deepin上qemu+kvm装黑果：启动 三大件准备完毕，我们需要先执行一些准备工作： 打开kvm参数：echo 1 > /sys/module/kvm/parameters/ignore_msrs，不这样，就会显示boot:不断重复重启。 网卡和网络设置部分：Kvm会自己创建一个virbr0和br0（见控制台虚拟网卡default栏），为nat（Installing "virt-manager" automagically creates the "virbr0" local private bridge :-) ）。我们把osx网络与主机网络组成tap：sudo ip tuntap add dev tap0 mode tap sudo ip link set tap0 up promisc on sudo brctl addif virbr0 tap0 仓库脚本最后一般是用复杂命令行定义的VM和启动逻辑，这也是网上的教程常讲的主体部分（除了命令行，也有libvirt.xml版，但我们讲命令行版方便说明）： qemu-system-x86_64 -enable-kvm -machine pc-q35-2.4 -smp 4,cores=2 \ -cpu Penryn,kvm=off,vendor=GenuineIntel \ -m 4096 \ -smbios type=2 \ -kernel ./enoch_rev2902_boot \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -usb -device usb-kbd -device usb-mouse \ -device ich9-intel-hda -device hda-duplex \ -device ide-drive,bus=ide.2,drive=MacHDD \ -drive id=MacHDD,if=none,file=./osxkvm.qcow2 \ -device ide-drive,bus=ide.0,drive=MacDVD \ -drive id=MacDVD,if=none,snapshot=on,file=./'Install_OS_X_10.11.3_El_Capitan.iso' -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -device e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 \ -monitor stdio kvm=off，并没有使用kvm半虚拟化加速。 penryn,pc-q35-2.4，这是qemu虚拟出来尽量按近mac的cpu和主板机型,q35使用osx硬件采用的ich9芯片组。 -smbios type=2 seabios patch,required for booting [Mountain]Lion 我们注意到device isa-applesmc,osk=“”这行，对应somlo old文，这是Mac专属硬件，用程序算出来的 urhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc这是固定的。 修改好boot,qcow2,iso各文件对应位置。 如果是-usb -device usb-kbd -device usb-tablet要改成-usb -device usb-kbd -device usb-mouse，否则moniter stdio下没有鼠标（usb-tablet后期在系统运行时可以有另外的开源驱动用）。 Ich9-intel-hda声卡 注意到虚拟网卡-netdev 开始的部分，这是最大的坑，作为黑果特例，网卡单一e1000是osx普遍内置的，net0是osx内部用的名字。52:54:00是osx合法的开头，见https://github.com/kholia/OSX-KVM/blob/master/networking-qemu-kvm-howto.txt,你还可给osx guest设置更复杂的bridge网络。 （也可以后期装virtio net pkg） -monitor stdio使用原生kvm窗口。也可以spice或vnc （这是整个osxkvm黑果的技术主体，也是pc黑果的技术主体https://www.insanelymac.com/forum/topic/278638-enoch-bootloader/，之所以以上都能轻描淡写做进命令行，是因为它们被解决了，从中我们看到somlo old文对应所提到的大大小小的坑,还有日渐功能丰富的qemu也会将它们整合包含(somlo文中一些对kvm本身编译更改的在qemu更新版中不必再做了)，故，以上在考虑将osx移到云主机时就需要逐个攻破，从qemu重新转到guest内，让kvm guest自包含而不是外部喂给，或依赖host qemu） 启动脚本boot-macOS.sh，显示虚拟机启动窗口。开头显示r2839字样，ehci warning: guest requested more bytes than allowed，接processing error - resetting ehci HC,但可以继续。如果不是r2839就启动不了。显示osx的recovery安装界面，进去，格式化磁盘，取个名，cp -av /Extra /Volumes/磁盘名（这个时候我们处在iso的文件系统中，extra就是写入的那些扩展,其实也就org.chameleon.boot.plist一个文件Chameleon configuration:timeout,To automatically boot into OS X without needing to press enter at the prompt，The EthernetBuiltIn and PCIRootUID keys fix the “Your device or computer could not be verified. Contact support for assistance.” error when logging in to the App Store.，主要是配置一些启动参数，没有kexts注入），继续安装。 如果在这里碰到No packages were eligible for install，一种解法是网上说的修改时间，如果点选左下角定制的时候，注意到osinstallsciprt为0kb，应试是镜像做错了，再次做好镜像即可。 —— 至于加速的和硬件直通的kvm osx。你需要更深入。这样的方式使用黑果是不是违法的，因为硬件就是 apple规约中的那些，apple并没有规约硬件的外层或外延。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
在阿里云上安装黑苹果的一种设想
本文关键字：在阿里云上安装黑苹果，省事方案之把osx icloud当nas用 我们为什么执着于在云上安装黑苹果，其实我们的目的不是使用osx的工具链和编译环境，以我个人来说，我只是喜欢iclouddrive。它有着极快的同步速度，和极科学的同步算法。而且与finder集成。使得osx即nas，可以很容易做成异备，而且它的客户端app即服务端app的结构，使得如果本地osx结合云上osx，能容易打造出一台省事的nas。这些在前文《聪明的Mac osx本地云：同一生态的云硬件，云装机，云应用，云开发的完美集》中我们都说过。 在《在阿里云上装黑苹果（1）》和《在阿里云上装黑苹果（2）》文我们讲了一些有关这个话题的可能性和资源。 uefi可以理解为就是一类pc（支持uefi代码的），另一类就是我们用了很久的bios机器，强调机器是不是bios或uefi，主要是它们与os安装这个关系上产生了联系，有些os同时支持bios和uefi下的安装，有些os仅支持uefi（最新的osx），有些pc可以同时工作在bios或uefi下。（通过开机设置切换）有些只能工作在bios下(如guest云主机）。——— 即，bios,uefi是机器从固件上如何工作与os安装支持发生关系的二种方式。 要让这个uefi发挥作用，在安装os时，特定uefi firmware往往安装在硬盘中某特定分区，所以它又涉及到了分区格式。一般地，bios机用mbr，uefi机用gpt，现在的机器，一般可以这二种方式，现在的os也一般同时支持bios+mbr方式或uefi+gpt方式安装（2者居1）。当然，也存一些混合的方式和分区格式可以允许某os从mbr+gpt分区上安装启动（如bootcamp）。但要实现直接让一个不支持uefi的os支持bios方式安装则要难得多，—— 这里的本质问题，首先是firmware，并非分区格式。虽然相关但前者是机器本身的问题，后者无足重轻。 那么，黑群晖能不能在云主机上安装，问题的关键在于，1，云主机是没有uefi的。只有bios，除非那种能nested kvm的。能以软件方式喂给uefi。2，能不能有一种方式，使得改造osx或找一个特定的osx，使之在bios+mbr也能完成安装，(osx catalina 10.15能经过patch以mbr的hfs+启动)，3,如果2能解决，那么在guest云主机是不是还满足这个osx的其它硬件支持，如cpu是不是支持sse，osx是不是支持virtio盘。4，如果2不能解决，那么安装一种clover类似的启动器能不能帮忙解决(clover这类virtual uefi的作风就是在bios或uefi机上利用软件生造出一个新的类uefi层———能引导osx的固件层。原理与uefi类似)。依赖它guest 云主机不能虚拟成支持uefi，但能引导osx所需要的固件环境就够了。5，启动了osx rececvery是不是就算成功了呢？不是的。osx本体跟黑群晖不一样，不是所有的驱动都做在loader中。系统只是升级数据包。osx recovery跟osx有独立的os级的驱动。正是osx本体的驱动判断cpu是不是支持sse4这些能不能运行的后续过程。 如果2，3，4都能解决，实际上在guest上安装黑osx是完全可能的。我们选择的机型是阿里云的至强cpu类型支持sse4的，kvm+qemu是半虚拟的，所有的硬件中，cpu是host的，但是是直通到guest的，所以也算是guest的，virtio是guest自己的，这样的guest机是完成可以安装osx 10.10以上系列的(裸金属是调度器级别的有专门的硬件，不存在虚拟化，而阿里云机属于流行的半虚拟机和全虚拟化，都在os内核中做了手脚外加CPU vtd支持，kvm,xen属于半虚拟化)。 验症了事物的充要性，（模拟硬件和适配镜像，始终是问题最大的二个坑），已初步排除一个，下面就是完成镜像，制造一个能bios+mbr安装运行的osx dd直装式镜像，这二个过程实际是一个过程。我们可以在本地建造kvm+quem虚拟环境。我们选择的是osx 10.10，据说这个版本最温和可驯，实用性也接近最新推出的osx10.15,其它的版本也可以依理尝试。测试好了。就导出。 ps:这个其实google一下，网上有。 搜索Catalina MBR HFS Firmware Check Patch 10.15.x可得。 话说回来，为什么我们不提倡在云上完成安装过程，使用“正规黑苹果”的那种方式（这个说法不可笑，黑苹果黑的是硬件和loader，跟黑群晖一样，不黑安装包）。因为我们有installNET.sh这样的东西，这更符合云装机的风格。我们在本地，也有工具和资源模拟这样的制造环境。—— 而且，结果跟一步一步安装得到的结果并不矛盾。—— 更并且，有了一个dd image，这样以后在白苹果上安装更方便（不用再依赖recovery或usb那套了，而这，dd这不就是ghost或timemachine吗）。 最终继续实验以实证。把镜像上传到云主机实测，如果不行，反复测试。 ————— 下文就是《省事方案之把osx icloud当nas用》，这样省事个人云系列1，黑群，2，黑果，3，自实现，都有了，就算基本有了精神本体了。恩恩 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
Dsm as deepin mate(3):离线编辑初始镜像，让skynas本地验证启动安装/升级
本文关键字：啥是真正的黑群，压缩skynas磁盘布局为5G内 在《dsm as Deepin mate(2)》中，我们讲到了使skynas镜像脱离aliyun ecs真正能运行起来的方法。但是我们用的是倒叙的手法，我们还没到得到安装镜像，这里继续。讲解离线创建和编辑纯净镜像，使之能像普通黑群一样启动，完成安装/升级的方法。 Ps:啥是真正的黑群 ————所谓黑群晖,是由于群晖基于linux gpl要求开源了早期内核和toolchain在sourceforge：http://sourceforge.net/projects/dsgpl/files/，而它的rd.gz,pat升级/安装包是很容易解包打包的https://github.com/andy928/synochecksum。因此。各种黑群技术有机会修改zImage,rd.gz和重新打包定制pat。你可以在这里定制内核插入你的驱动，作各种脚本增强，使群晖适用于更多机型，甚至通用硬盘。故，其实正真被黑的部分并不是bootloader。正真被黑的应该是部分内核zImage与位于initrd ramdisk中的各种外挂模块。至于系统中的安装包/升级包中的正常具体逻辑，是不需要破解的。虽然如此，大部分黑群版本命名大都是xxxboot之类。具体技术方面，（1）破解的第一关是rd.gz中的synobios：群晖是通过一个叫做synobios.ko的外挂模块集中处理硬件绑定问题的。一旦破解了它,很容易解除硬件绑定关系。所谓的破解，主要就是改一下这个接口的代码，使他在黑群晖的硬件上也能返回一个合法的机型代码（例如DS3612xs的代码是42）。因此，大家现在所安装的黑群晖，实际上synobios.ko文件已经修改过了，镜像pat也用的是重新打包过的pat，synochecksum-emu1 hda1.tgz rd.gz updater VERSION zImage >checksum.syno这里有一个对pat内文件验证打包的过程。(2)破解的第二关，群晖在sourcefourge的开源内核驱动仅支持官方，本身也是有点错误的，需要一定定制，加入自己的驱动，直接编译后在引导系统的时候会出现很多错误，例如加载synobios时候出现找不到符号的错误、synoacl实现并没有完全开放等等。因此，需要对synology开放的内核代码做一些修改，目前网上能够找到的对内核的修改只有旧内核的(3.2.11等）。加入自己的驱动，等等。（3）还有一些边角的破解或增强，如修改u盘vid和pid,填写正确的U盘 VID和PID可以在DSM界面隐藏U盘，修改sn和mac地址可以用于"洗白”。可见sn破解是无关紧要的，除非你要用上官方的服务如quickconnect,ffmpeg缩略生成等（见前文后面，本地验证版黑群，官方只是没有对这些假sn开刀而已）。http://xpenology.com/wiki/en/building_xpenology可以说是一篇最详细和权威的资料（编译内核的内容，还包括了synobios的破解和rd.gz的制作，etc..），不过它是是针对4.1的老版本的。不过其用于指导黑群制作的思路是不变的。视上面二方面，加入了不同驱动，作了不同增强，因此有很多黑群版本，虽然定制synobios是不可避免的，但有的版本，如gnoboot支持使用官方的PAT文件（依然是xpenology的思路），gnoboot编写了一组脚本，巧妙的实现了在rd.gz引导系统后自动替换需要破解的文件，不仅如此，gnoboot还包含了大量的驱动，并且可以很方便的加载和卸载驱动。————— 问题回到出发点，对于skynas,破解目标是什么?对应上面提到的(1)（2）（3）有哪些地方需破解呢？第一个问题，不经过破解直接运行的结果，就是用你提取的安装镜像换机安装时，不会启动sda5中的系统安装无法继续，而是进入web assit重装界面（即用当初收费镜像机dd出来的机器镜像，换机后也有绑定过期验证不通过退回webassit重装界面），这个绑定在哪？是不是验证？这就是第二个问题。 作初步猜想，可能在grub的那个checksum（zimage,rd.gz,update.pat/hda1.tgz三个都是阿里云绑定的因为其内都有aliyun_xxx相关的脚本文件,不排除是这个原因导致的安装验证不通过。rd.gz/synobios应该不需要破解因为都是阿里云机。那么那个checksum呢？），也有可能在sn绑定（因为skynas是个在线机器,有先sn网络验证后安装的条件，不过群晖并不常用sn验证安装过程,物理机上的黑群boot通过了就通过了）。 无论如何，skynas用的并不是严格普通黑群的那套(不是synobios过了，pat就会过)。而是只有zimage,rd.gz,update.pat三个都过了，才过，所以破解会是（1），（3）我们需要测试验证，下面会讲到。 镜像及镜像离线编辑测试环境 我们先来尝试建立一个纯净镜像，去阿里云开一台系统盘为20g的skynas615-15254(选择可卸载)按量机器作测试环境（为什么不在本地虚拟机测试呢？因为我们还没有精力去考虑因换本地可能带来的其它情况），开机后关机，恢复系统盘初始状态为skynas615-15254选择不重启，建立快照。 —— 这样我们就得到了一个初始skynas61515254的快照。重置系统为ubuntu18，并启动，为只有一个系统盘的系统建立一个20G的数据区，建立时恢复skynas快照并mount。 反转数据区与系统区启动逻辑(为什么要反转呢，因为我们未来要在系统区安装skynas运行测试镜像，启动到数据区上安装的ubunt18里离线编辑，grub1,2可以互通)，在ubt18中初步编辑skynas/vda/boot/grub.cfg建立启动到第二硬盘的菜单，像这样： timeout由15改为1500,如果这个不改，从vnc重启，如果过快，会默认启动到skynas。加一个菜单boot ubtset root=(hd1,msdos1) 这里是vdb中的ubt,从grub1 chainload grub2，反之需要insmod ext2linux /initrdinitrd /vmlinuxboot 删掉原来快照重新建立数据区的新快照 ——— 这样我们得到一个初步修正了的skynas的快照。同时，系统区也做快照。—— 这样我们得到了一个ubuntu18的快照。 现在，使用阿里云最新的功能卸载系统盘和数据盘，为没有任何盘的系统重新建立一个20G的系统和50G的数据（这里为什么先前要卸载系统盘呢，因为不是新建的盘不可以从快照中恢复，我们也不想使用镜像功能因为那会涉及到计费），建立时恢复新skynas的镜像，如上所述，我们将在这个ubunt18里离线编辑(为什么ubuntu18里面不同时装我们以前文章中处处使用到的tinycorelinuxpevirtio呢因为tcpe毕竟有些工具版本有限不太方便)，在skynas盘运行测试镜像（为什么不在数据盘里运行skynas呢，因为skynas kernel的root必须是sda系列，而ubt怎么都可以），这样我们就得到一个离线编辑运行镜像的测试环境了。 vnc重启，进入skynas的菜单，选择启动到vdb上的ubuntu,在ubunt里，dd( + status=progress可看进度)数据区到系统区root下形成img.gz文件。得到一体化灌装好的一个初始镜像615-15254.gz，这也是阿里云初始sky nas 镜像用的方式，(并非用任意pat通过webassit直装)，mount /vdb5可以看到它是如下这样组织的，像这样： .SynoUpgradeIndexdb.txz.SynoUpgradePackager 猜出现在package center的是丢在pat/package升级包中提取出来的.SynoUpgradeSynohdpackImg.tcz.NormalShutdown…..然后是hda1.tgz释放到整个sda5中的内容 其实不嫌麻烦，你可以利用前几篇文章中的方法或重新建立分区，研究手动释放DSM_SkyNAS_15254.pat升级包到vdb5得到如上组织的方式。 绕过验证逻辑 这样三者(kernel,rd.gz,pat)都有了，synobios略过，来看grub中的checksum，它相当于物理机中pat中的checksum，checksum是check rd.gz+zimage的。如果修改rd.gz，checksum会failed，但它会不会影响rd.gz中的逻辑呢。如果验证逻辑主要在rd.gz中呢？（这个在gui桌面环境下用7z就能打开查看,里面有大量的可能验证逻辑），不论如何，先验证一下修改rd.gz使checksum失效吧，看会有什么影响。 我们首先测试来为rd.gz中的root去掉内置默认密码，以证实我们的想法和利于接下来的分析，:etc/passwd去掉第一对::中的x,/etc/shadow去掉第一对::中的*，如下作重新打包即可： (我们现在在/root，mount /dev/vdb2 mnt/vdb2, cd mnt/vdb2,vdb2空间足够，可以直接在这里修改和重打包,首先把rd.gz改名为rd.gz.xz,不然接下来xz解压不成功) (解压) mkdir rd.dir cd rd.dir xz -d -c -k ../rd.gz.xz | cpio -id (压缩) cd rd.dir find . | cpio -o -H newc | xz -9 --format=lzma > ../rd.gz （测试1）重启测试新的rd.gz,即boot sda2启动菜单中去掉checksum和vendor。此时进去/sda5/etc/会发现大部分rc都是加密的。原来checksum只够影响这里。 （测试2）重启测试新的rd.gz,即boot sda2启动菜单中保留checksum和vendor。此时进去/sda5/etc/会发现rc都是正常的，只是显示checksum处显示failed，而且linuxrc.syno failed on 4。但此时系统依然无法启动。，启动后。依然如意料只会停留在web assit界面。 看来checksum并不是最终验证或唯一的过程。使得这个升级过程不能继续。我们需要探索更多rd.gz中的地方。接下来就是初步分析整个rd.gz，去得到绕过验证的逻辑，然后动态修改rd.gz，并用新的rd.gz用在系统区中启动。一点一点测试，这是我们的新思路。 我们结合dmesg,从linuxrc.syno来一步一步分析。这里的流程是rd.gz/linuxrc.syno(rd.subr)->/etc/synogrinst.sh(rd.gz/usr/syno/sbin/installer.sh,update.sh)->sda5/usr/syno/etc.default/aliyun_sn_init.sh,sn_generater在第一次启动后（无论成功或失败）会自删掉 我们从上面找到了，从rd.gz到sda5 privot root的地方(rd.gz/linuxrc.syno，rd.gz/etc/rc中的mount /dev/root /)。 貌似在upgrade输出，准备升级开始的地方。如果找不到/dev/root就找不到/tmp/root等如果找不到分区，就找不到/dev/sda找不到/dev/sda，针对sda就全盘cfgen不了，就导致linuxrc.syno启动失败(upgrade过程)如果upgrade不了，就形成不了整个有效可启动的/dev/sda5 正是这里导致了linuxrc.syno failed on 4，最终就只能进入rd.gz 因此，所有的问题都变成，如何触发 让rd.gz过程找到/dev/root(就会启动/dev/sda,事实上绕过了验证) （最终成功测试）解发能找到分区的关键是，安装过程中要有一个/dev/sdb，跟前文一个思路和技术。 (最后来说那个sn) 其实那个序列号只是系统内一个叫sn_generater的本地工具随机生成的。有没有那个sn没关系,系统可以以空sn安装启动那个aliyun_sn_init.sh和aliyun_sn_generater是临时生成的。 封装和后期离线编辑过程 最后是封装：dd到ubut分区中,及后期离线编辑： （没有kpartx，我们可以用loop) losetup -f losetup -o 1048576 /dev/loop0 skynasinit mount /dev/loop0 /mnt/volume1 losetup -o 17825792 /dev/loop1 skynasinit mount /dev/loop1 /mnt/volume2 losetup -o 122715648 /dev/loop2 skynasinit mount /dev/loop2 /mnt/volume5 umount /volume5 losetup -d /dev/loop2 上面-o 之后的数据就是skynas的四个分区开始乘于512得到的 (如果volume5 umount不了,我们可以找出占用volume1的在执行进程并终止它们) lsof +f -- /volume5 Kill -s 9 pid —————— dsm的web后台技术做得很流畅很轻量不费资源，还有webassit在线安装升级是syno的二个特色（从这里我们可以分析得到其边分区边升级、安装的技术）。结合前文《Dsm as deepin mate(2)：在阿里云上真正实现单盘安装运行skynas》，甚至你还可以压缩skynas磁盘布局为5G内，这样镜像做出来也会更小,集成更多内置spk和一个叫move_syno_pkgs.sh的脚本，etc…..前文遗留问题：有一些spk如vide,photo只能在有单独hd as volume的情况下安装,把sdb1改成sda4 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
硬件融合的新起点：虚拟firmware，avatt的编译(2)
本文关键字：硬件融合的新起点 , 融合PC和手机，操作系统并启/网装法,真正的virtual app 在前面《在阿里云上装黑苹果》时我们谈到clover,它是一种能虚拟硬件的EFI而不仅仅是一个loader，其改写硬件逻辑的作用，是重启后依然存在的。（所以，它有可能对硬件造成损伤，切记不要在白苹果上使用clover，mbp使用clover丢firmware和坏屏的例子不少）。从虚拟EFI，到后来，我们又谈到parallel os bootloader和将hypersior集成到loader的设想，并最终发现了coreboot，而它居然可以集成linux和虚拟机，。。。。。这种loader层和firmware层面的虚拟化层面，为PC和云裸金属提供了一个地道的虚拟化层面。即firmware as infrature技术,它使cb进化到了具有融合硬件的作用，试想一下，现在的PC和移动端越来越强大，注重融合体验，可是都做得不够好，而如果走让不同的融合设备共享同样的infrasture，即统一硬件的路子，，就可以解决很多以前不好解决现今统一上层之后变得很好解决的大部分问题。 其实这个我们在《为你的硬件自动化统一构建root和firmware》也隐约提到过如，虚拟机virtual applicance 这些（vs webapp,nativeapp,etc..）都不好用，purism一体linux phone,laptop。现在放大来讲一下：现在做的桌面移动统一，都是从生态上整合，因为技术上内核从一开始就不一样。上流决定下流，这样会产生很多问题，兼容，适配，开发，separated codebase for different hardware。故，桌面移动统一，需要从硬件生态提出一个firmware层。之后所有的终端，不管你是谁，一律使用用户态OS即可，这种使用从firmware层（技术层）的融合可以解决绝绝大部分问题。比如一开始我们追求的OS并启，OS网装法，还比如类似上面的purism：使笔记本和手机共享无缝使用同一种linux，所有这类问题它都可以解决，以后就不用再使用chroot这样的技术给手机换OS了。还可以带来新的创新视点：还比如，基于融合OS上的融合语言层和融合开发层，如 as Devops tools（这其实是cb的一个辅助作用属工具性质）。还比如使用hyperkit统一虚拟化和容器技术，。使得虚拟机直接成为app runtime，提出真正的virtual app。就像GO语言的整合粒度那样。 关于硬件融合设想 一个人其实基本上会用到各种硬件几件套，手机和PC，还有NAS，,办公PAD，编程pad，游戏pad。作为一个编程者需要接确到的OS，1，PC：装客户OS和NAS OS，同时运行，2，手机端装programming os和nas 客户端OS,试想下这些都能实现在现有硬件上。 因为你不是硬件厂商，我们只能从换firmware开始做融合硬件，有一些coreboot for phone的方案也在慢慢出现。其实coreboot也有for andriod后端，你完全可以通过这种技术给andriod手机写linux OS。那么laptop呢。最好的测试平台是买一台chromebook,测试cb的最好平台也是cb，google的pixel book和pixel手机总是第一时间被coreboot支持，至少早期的硬件性能不够就不要考虑了，如ubuntu touch刷早期 meizu之类的方案，当然对于programmingpad，我们做不了纯粹的融合硬件设想，比如像带实体键盘的programmingpad(实体键盘与触摸主要是一个能不能盲打的区别，这跟键子的边沿设计有关可以用键盘膜)，也不好直接从黑莓,titan上做，就不考虑。 总之，虚拟firmware似乎是融合硬件的终极大法，甚至还有人做成了融合ios: Corellium此类方案其实也是从firmware层着手，如同clover for Mac，Phones using coreboot Corellium iOS Kernel Research Virtual iPhone Hardware. Corellium virtualizes any mobile device hardware through software platform and allows you to test on various different devices without actually having physically had those devices. This is not the same as simulation as we get with Xcode and with other platforms where you would just simulate the iOS on a different iPhone through the Mac. this is actually a virtualized hardware it’s going to be basically a one-to-one clone of the device as if the device was a physical devices. 要使用这个刷机系统和得到想知道的私人信息，你访问他们官网发邮件，回复要100万美元.. 后来我们还编译了avatt，研究了coreboot的自动化脚本技术,这里继续： 编译avaat(2) 在前面我们buildroot讲到会生成到vmlinux，vmlinux集成了ramfs的rootfs，在buildrom里会生成到work/coreboot/svn/targets/emulation/qemu-x86/coreboot.rom，最终cp到deploy，所以这是一种从Vmlinux->到payload->到rom的过程，那么我们如何在packer中自动获取这个deploy到host呢。 我本来企图用virtualbox-ose-additions-modules-2.6.33.3-tinycore.tcz在packer中装guest iso和设置packer的shared folder来实现。无奈几次都没有成功。所以，为了省事，最后找到这个，写在dbcolinuxbases.virtualbox中： dbcolinuxbases.virtualbox中的改动 … {"type": "file","source": "/mnt/hda1/tmp/scripts/buildrom/buildrom-devel/deploy/*","destination": "/Users/admin/Packer/output/","direction": "download"} 此除之外加上这二句，让packer变得更像vagrant一点: "skip_export":true, "keep_registered": true 还得加一个tce-load -iw python.tcz在适当位置 make.sh中的改动： 最后，由于packer是按上传给他的sh来检测改动，并在一次retry中生效的，形成一次debug，为避免debug周期过长，我们需要把make.sh多做几个脚本放开调用，这样可以避免修改一个sh后retry的等待时间过长。 上次讲到在coreboot编译时，这里继续 Package/coreboot-v2/coreboot.inc中把svn逻辑改为wget，由@ $(BIN_DIR)/fetchsvn.sh $(CBV2_URL) $(SOURCE_DIR)/coreboot $(CBV2_TAG) $(SOURCE_DIR)/$(CBV2_TARBALL) > $(CBV2_FETCH_LOG) 2>&1 改为：@ wget $(WGET_Q) -P $(SOURCE_DIR) $(CBV2_URL)/$(CBV2_TARBALL) 如果之前没有安装python.tcz，那么这里还会有：virtualbox-iso: ./buildtarget: line 49: python: not found 好了下面来开放那三个在《编译avatt(1)》中禁用的三个虚拟机相关项，qemu和ovzctl,ovzquote，我们只开放后二者，因为kvm在avatt中是不能用的。 vzctl-3.0.23 Vzctl.mk中，我们看到整个br的逻辑其实是一个wrapper.从这里可以看到vzctl采用的是package的自动，属于vzctrl.mk中尾端的那个调用。里面AUTOTARGETS是来自package/Makefile.autotools.in，里面define AUTOTARGETS $(call AUTOTARGETS_INNER,$(2),$(call UPPERCASE,$(2)),$(1)) endef，参照vzctl，找出qemu patchs的位置是package/buildroot-libtool.patch， 我们看到执行vzctl.mk会下载到正确的vzctl-3.0.23，但是编译的时候出错： ==> virtualbox-iso: mkdir: can't create directory '/mnt/hda1/tmp/scripts/buildroot/project_build_i586/avatt/root/etc/vz/dists': File exists 将vzctl.mk中的VZCTL_INSTALL_TARGET:=YES改为NO。因为这条重复了。 相反，对比vzquota-3.0.12 vzquote.mk，我们看到它主要是mk中的逻辑。没有使用到auto wrapper，其实vzctl本来就是用libtool和autotools编译的，所以会用到此auto wrapper。而vzquota不用。 一路通过。vzctl和vzquote会生成在ram rootfs的/usr/sbin,buildrom-devel/config/payloads 中运行这个rootfs的是COMMAND_LINE=console=tty0 console=ttyS0,115200 rdinit=/linuxrc 好了。最后。让我们本地用qemu测试运行导出的rom。进入本地output文件夹： qemu-system-x86_64 -bios build/emulation-qemu-x86.rom -serial stdio 不加serial，会发现运行命令的那个console窗口和打开的graphic窗口都不显（这里显示payload,加-nographic可以让这个graphic不出现）。-serial stdio是让一切显示在console,可是我们发现在console窗口中在出现rootfs登录提示符前卡住了，上面的cmdline又是正确的，问题只能出在sket.tar.gz中，修正target_busybox_skeleton和target_skeleton中的/etc/inittab： # Put a getty on the serial port # ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL 将ttyS0前面的#去掉。 终于出现avatt命令行了，你可以在这里root登录。你还可以在运行qemu-system-x86_64后加-hda xxx.image -m 1024 -net nic加硬盘，内存和网卡，当然这个rootfs似乎并不好用(target中只开放有限工具，甚至fdisk都没)，都甚至不能完整分配硬件资源测试ovz。需要修正。ovz也是32位的只认有限内存。 未完待续。 ——— 通用系统网装法，现在是网络时代，只要保证bios不死，如果还停留在u盘装机时代就OUT了。我们现在是用qemu运行，那么如何把linux不刷机弄为虚拟efi运行呢。比如放在efi文件夹就如同clover那样，不过这样就不能打造不死bios了。以后尝试。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
将虚拟机集成在BIOS和EFI层，vavvt的编译(1)
本文关键字:corebootv3低版本编译,让dbcolinux用上buildroot,在tinycorelinux上编译coreboot,kvm-coreboot,ovz-coreboot 在前面《为你的硬件自动化统一构建root和firmware》文中，我们讨论了为平台和硬件自动构建linux dist的buildroot和coreboot(buildrom)方案。在那里，我们研究的是最新版的源码。文尾我们还谈到要把这一切port到cohdevbox srctree中且使用osx vagrant+plain qemu thru somewhat “libvirt plugin” under linux(毕竟qemu既是个模拟器也是虚拟机)，却发现遇到了几个困难：1)市面上却并没vagrant-libvirt to run qemu commands directly，vagrant与packer的插件都是面向kvm/qemu的。2）且osx下，与libvirt/kvm/qemu等同的方案却是xhyve thru vagrant-xhyve，3）第三，cohdevbox/dbcolinux的packer构建中我们是基于tinycorelinux384 32bit来进行对dbcolinux深度目录定制的，里面的kernel都是2.6.x的。且4）第四，要考虑集合进openvz/kvm as coreboot payload，即把buildroot和coreboot一起使用，比如coreboot会使用buildroot出来的结果。 —— 所以，源码的版本选择可能需要更好处理，困难4也可能会难于解决，不过，幸好之前我们也进行过在dbcolinux中集成ovz的工作研究。另外，我们还找到了avatt : all virtual all the time，avatt is a buildrom-based buildsystem that can be used to build a virtualization-aware BIOS based on coreboot using KVM or OpenVZ (latter is currently work in progress)，是20090705的一个项目https://repo.or.cz/avatt.git/commit/1ee14af6661f1ebb0f18b9d1241ef1a67278c5ab。它整合了buildrom(coreboot早期的自动化构建脚本，此功能最新版coreboot已整合)和buildroot并加了自己的一些default configs和patchs，avatt/buildrom可参见https://repo.or.cz/buildrom.git/commit/4f38d5c4d9e8cdb99fcb2bd5aac859605d46e4ef，其大约是coreboot V3一期的东西，至于avatt/buildroot,也是mirror的buildroot同时期的东西，值得一提的是其主要选择了ublic和i586作为target。 这成为我们本文将buildroot融合到cohdevbox srctree中的最好尝试。鉴于困难1，2我们依然选择使用packer而不是vagrant，这里使用virtualbox而不是PD（主要是PD business版商业化太麻烦，另外，还记得在linux上我们使用过packer+vmware?）。 准备工作 定制一下packer的启动。在start.sh中。 export PACKER_CACHE_DIR=~/Packer/cache，加了这个可以将cache移出当前目录。比如你可以将它放到与>> output_directory（~/Packer/output）同根下一起。packer build -force -on-error=ask dbcolinuxbases.virtualbox，加了force可以在每次clean后不用手动去删临时文件。 新的dbcolinuxbases.virtualbox文件里会是这样： >> "type": "virtualbox-iso", >> "guest_os_type": "linux", >> "hard_drive_interface": "ide",之前在PD上，现在VB上这二个都是默认的others,ide，但一定要加。以免不创建硬盘。空>> 间是默认大小的。Guest os一定要是某种linux，否则无法启动某些TC grub条目。 >> “cpus”: 2, >> "memory": 4096, 其默认"guest_os_type": “other”,只有512m，不足于编译GCC时内存用量，加这个就可以在不用提及>> guest type的情况下配置内存用量。 >> 我们调整了srctree下目录，将各种src和tc.iso,tc下各种3.x/pkgs全移到res下。srctree/中只保留res和scripts(里面是整个>> avatt源码) >> "http_directory": "res/", >> 我们固定了port，而不用脚本中使用HTTP_PORT参数。虽然硬编不够灵活，但可以免除一些麻烦 >> "http_port_min": 8000, >> "http_port_max": 8000, >> 在上文《利用hashicorp packer把dbcolinux导出为虚拟机和docker格式（3》的基础上。我们在"boot_command”中新>> 增这二个包。 >> "tce-load -iw bash.tcz<return>", >> "tce-load -iw texinfo.tcz<return>”, >> "tce-load -iw tar.tcz<return>”, >> "tce-load -iw quilt.tcz<return>" >> 除此之外，"sudo sh -c 'echo http://10.0.2.2:{{ .HTTPPort }}/ > /opt/tcemirror’”,因为我们换了网络地址。 >> "provisioners”中，除调用Bootstrap.sh保持不变。传src，也变成传scripts，和一条调用make.sh >> {"type": "file","source": "scripts","destination": "/mnt/hda1/tmp"}, >> {"type": "shell","pause_before":"1s","execute_command": "echo '' | sudo -S sh -c '{{ .Vars }} {{ .Path }}'","scripts":>> ["./scripts/make.sh"]} make.sh的内容： >> cd /mnt/hda1/tmp/scripts/buildroot/target/generic/ >> tar zxf sket.tar.gz >> 如果不加以上，上面的传scripts会不成功。所以需要处理源码，除了generic中的，删掉scripts其它所有>> target_busybox_skeleton，target_skeleton，把generic这二个文件夹打包成sket.tar.gz放在generic下。 >> cd /mnt/hda1/tmp/scripts/ >> sudo make defconfig >> sudo make >> buildroot的整体逻辑与流程。我们看到defconfig实际上就是buildrom-defconfig加buildroot-defconfig，先后顺序很重>> 要。都是把.config先复制出来，然后sudo make 在packer中测试编译Buildroot 上面准备工作完成之后，启动start.sh,进入条件测试，如果没有bash.tcz，可能会出现相关错误Retry，会出现一些常见下载错误。首先是wget命令。这是因为tc384中的wget版本过低。==> virtualbox-iso: echo "2009.08-git" >/mnt/hda1/tmp/scripts/buildroot/project_build_i586/avatt/root/etc/br-version==> virtualbox-iso: wget: invalid option -- 'n'Buildroot.config里面，去掉BR2_WGET="wget --passive-ftp -nd”中的-nd，retry 接下来的这些下载错误，属于文件没找到错误，基本在buildroot.config或packages/xxx/xxx.mk中可以找到修改地址的地方。将其找到，一一修改为正确的调用packer http sharing的逻辑： 找不到linux-2.6.26.8.tar.bz2，BR2_KERNEL_MIRROR="http://www.kernel.org/pub/" 按路径改这个>> http://10.0.2.2:8000/src/dl/Retry,找不到uClib-HEAD.tar.bz2,去uClib.mk，UCLIBC_SITE:=http://10.0.2.2:8000/src/dl/uClibc/snapshot。snapshot>> 等这种命名是ulibc的源码发布方式。这里的uClib源码要找0.9.30，在本地解压重打包成uClib-HEAD.tar.bz2，>> 记得里面的顶层文件夹uLibc-0.9.30改成uLibc-HEAD，如果直接用官方最新的，1)可能编译过程会找不到配置需要你手动>> 配置。也会出现error: pthread.h: No such file or directory对应不到头文件。2)高版本gcc编译低版本uclib及kernel会出>> 现unifdef.c 中的 getline 提示重复，将extra/scripts/unifdef该文件中getline全改成get_line，有三个地方。Retry,找不到mpfr-2.4.1.tar.bz2，mpfr.mk中，改MPFR_SITE:=http://10.0.2.2:8000/src/dl/mpfr-$(MPFR_VERSION)，>> patches文件是mpfr-2.4.1.patch，同样放到mpfr-2.4.1/下，会在虚拟机自动被下载并命名成mpfr-2.4.1.patch。Retry,找不到binutils-2.18.50.0.9.tar.bz2，改BR2_GNU_MIRROR="http://10.0.2.2:8000/src/dl/gnu”，binutils包放在>> src/dl/linux/devel/binutils下。retry,如果出现binutils/objdump] Error 2，则是因为makeinfo没有安装，如果出现unknown command `cygnus’，临时>> 解决办法是将shell texinfo降级到4.13，通过下载编译源码编译安装比较老一点的版本。幸好tc384的makeinfo足够低。Retry,找不到gcc-4.3.3.tar.bz2,gmp-4.2.4.tar.bz2,前面改过BR2_GNU_MIRROR,这里仅需将gcc包放到>> res/src/dl/gnu/gcc/gcc-4.3.3,gmp包放到src/dl/gnu/gmpRetry,如果出现bug出错字样,可能内存不够导致编译gcc失败。可以retry一次或者在配置文件中多加一点内存，预留的2G足>> 够。Retry,找不到ccache,改ccache.mkCCACHE_SITE:=http://10.0.2.2:8000/src/dl/ccache，包放好Retry,找不到module-init-tools,改module-init-tools.mk，包放到src/dl/linux/utils Retry,找不到linux-2.6.24.tar.bz2,之前那个2.6.26.8应该只是取得头文件用，这里才是编译真正的kernel用，改>> buildroot.config里面BR2_KERNEL_SITE="http://10.0.2.2:8000/src/dl/ovz,，注意前面的kernel是改>> BR2_KERNEL_MIRROR这里是KERNEL_SITE，有所不同。这里要放的包是ovz的linux kernel linux-2.6.24.tar.bz2，跟>> uClib一样要处理一下得到。直接下载legacy openvz的2.6.24-ovz008 branch 最新src tarball即可。重打包时保证包内根目>> 录为linux-2.6.24因为这里我们要绕过BR2_CUSTOM_LINUX26_PATCH="patch-ovz008.1-combined.gz"的下载及使用，因为这个2.26.24>> 是本来就经过了patched的ovz src，也发现二个BR2_LINUX26_CUSTOM=y和>> BR2_KERNEL_LINUX_ADVANCED=y要作何处理呢，这二不要动否则不会生成vmlinux。patch source的修改处为>> target/linux/Makefile.in.advanced：1)$(call DOWNLOAD,$(LINUX26_PATCH_SITE),$(LINUX26_PATCH_SOURCE))2)toolchain/patch-kernel.sh $(LINUX26_DIR) $(DL_DIR) $(LINUX26_PATCH_SOURCE)一个是下载，一个是apply patch，统统#禁用即可,其实也可在buildroot.config里找到开关：>> BR2_KERNEL_PATCH="$(BR2_CUSTOM_LINUX26_PATCH)”，置空””即可，我选择是前一种方法。 retry，找不到busybox-1.13.4.tar.bz2,改BUSYBOX_SITE:=http://10.0.2.2:8000/src/dl/busyboxRetry,找不到e2fsprogs-1.41.3.tar.gz，改e2fsprogs.mk中>> E2FSPROGS_SITE=$(BR2_SOURCEFORGE_MIRROR)/e2fsprogs和>> BR2_SOURCEFORGE_MIRROR="http://10.0.2.2:8000/src/dl”。Retry，找不到pciutils-3.0.1.tar.gz，改pciutils.mk中PCIUTILS_SITE:=http://10.0.2.2:8000/src/dl/linux/pci和>> PCIIDS_SITE:=http://10.0.2.2:8000/src/dl/linux/pci/Retry,找不到qemu-0.10.5，改qemu.mk中QEMU_SITE:=http://10.0.2.2:8000/src/dl/qemu/Retry，如果没有tar.tcz，可能会出现tar解压错误unrecognized option '--strip-components=1'。Retry，相当于在qemu srctree中make，结果出现==> virtualbox-iso: Makefile:3: config-host.mak: No such file or directory于是，在buildroot.config禁用BR2_PACKAGE_QEMU=y，BR2_PACKAGE_VZCTL=y，>> BR2_PACKAGE_VZQUOTA=y（Qemu应该是往kernel中加入kvm，后二者是加入Ovz?日后解决）Retry,找不到fakeroot_1.9.5.tar.gz，改fakeroot.mk中FAKEROOT_SITE:=http://10.0.2.2:8000/src/dl/fakeroot/retry，找不到genext2fs-1.4.tar.gz，改ext2root.mk中GENEXT2_SITE:=$(BR2_SOURCEFORGE_MIRROR)/genext2fs,>> 至于BR2_SOURCEFORGE_MIRROR在前面改过了。 终于到这里了，脚本将利用target_skeleton打包成，至于# BR2_TARGET_ROOTFS_EXT2 is not set，表示它并不会被使用，ext2的rootfs在嵌入式上很流行。但脚本默认使用了INITRAMFS,即BR2_TARGET_ROOTFS_INITRAMFS=y，它利用生成的rootfs.i586.initramfs_list文件。然后写入到echo "CONFIG_INITRAMFS_SOURCE="$(INITRAMFS_TARGET)\"" >> \$(LINUX26_DIR)/.config产生作用，这个linux26_dir是project_build_i586/avatt/linux-avatt-openvz，会在构建vmlinux时自动将rootfs整合到vmlinux内部。 整个此buildroot全程构建时间约<20分，若成功会在buildroot/binaries下会生成vmlinux(约4.4M大)，供后续buildrom使用 在packer中测试编译Buildrom virtualbox-iso: /mnt/hda1/tmp/scripts/buildrom/buildrom-devel/bin/fetchsvn.sh: line 9: svn: not found不需要tce-load -iw subversion,我们只需要按与buildroot那些下载逻辑一样。在buildrom的sources下载到它需要的Mkelfimage-svn-3473.tar.gz即可，Mkelfimage-svn-3473.tar.gz怎么来的？在github.com/coreboot/coreboot搜索带mkelfimage的commits，https://github.com/coreboot/coreboot/search?q=mkelfimage&type=Commits，发现https://github.com/coreboot/coreboot/commit/ebc92186cc9144aaacd37ca1ae94fcff60ec577a，这条刚好是以前通过svn导入的3473：git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3473 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1。下载其包文件解压源码，将其移到一个svn文件夹下，然后打包成mkelfimage-svn-3473.tar.gz，放到src/sources中。 再做以下必要修改：在mkelfimage.mk，改MKELFIMAGE_URL=http://10.0.2.2:8000/src/sources/mkelfImage，然后把下面一句由：@ $(BIN_DIR)/fetchsvn.sh $(MKELFIMAGE_URL) $(SOURCE_DIR)/mkelfimage $(MKELFIMAGE_TAG) $@ > $(MKELFIMAGE_FETCH_LOG) 2>&1 改为：@ wget $(WGET_Q) -P $(SOURCE_DIR) $(MKELFIMAGE_URL)/mkelfimage-svn-$(MKELFIMAGE_TAG).tar.gz ，这句是参照接下来unifdef.mk中取来的 retry,找不到unifdef,unifdef.mk中改UNIFDEF_URL=http://10.0.2.2:8000/src/sources/unifdefRetry,这里没有安装quilt.tcz会出现quilt:command not foundretry,找不到lzma443,lzma.mk中改LZMA_URL=http://10.0.2.2:8000/src/sources/lzma 脚本在将结束时将寻找前一步产生的rootfs和vmlinux。生成elf coreboot payload bios.然后启动coreboot的编译。 Retry,提示找不到coreboot-svn-3772.tar.gz，buildrom是将coreboot作为它的一个package的，在https://github.com/coreboot/coreboot/commits/master?before=91eb2816faa4b2689f30ca47ff2585cf79ac53f3+28735找到目标：https://github.com/coreboot/coreboot/commit/544dca4195a6fb77286299bf42d4db5813dc28ac，按上述类似的方法处理。 未完待续。 我们要做的，会慢慢精简它到固定版本的buildroot脚本,然后把定制目录的dbcolinux移进去。至于使用这个rom，我们可以将其刷入bios中（当然，涉及到很多适配工作）也可以放在efi分区中。用处呢？我们可以利用其虚拟机管理功能建立devops，或用于类exsi裸金属式装机，在这个rom中加入moeclub的脚本作netboot系统安装运维达到osx network recovery的效果且更灵活,比如，使用局域网wifi usb disk存储镜像在线安装系统。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
为你的硬件自动化统一构建root和firmware
本文关键字:Buildroot，coreboot as Buildrom 前面《基于虚拟机的devops套件及把dbcolinux导出为虚拟机和docker格式》系列文章中，参照LFS,我们曾手动自建过交叉编译环境和linux，完成了包括gcc as 开源toolchain,linux as os kernel，busybox as开源os rootfs,各种libs的所有手工化构建步骤，不过仅限于在PC上，和x86之间进行，都没有考虑进我们现在除PC外的其它使用linux的硬件，—— 这就是嵌入式平台及特化PC，它们甚至是我们目前硬件平台中的绝大部分，如路由器和手机(nas,laptop也算)，—— 虽然说linux对嵌入式都有支持，构建的流程大同小异。它们跟PC平台相比，对构建的需求还是有点不太一样： 首先，但嵌入式硬件多样，有着各种各样的非x86 CPU和cross compile需求，采用的一些版本也是PC上的特化版本，如libc。libc是程序与内核交流的媒介与用户编程接口，，嵌入式上往往使用ulibc. 而且，嵌入式中，firmware跟os,甚至app的界限非常不明显，往往高度耦合，前面我们在《Boot界的”开源os“ : coreboot，及再谈云OS和本地OS统一装机的融合》中说到，firmware编程是OS前面的那块软件编程，嵌入式平台的firmware与os往往高度偶合，往往firmware直接就是boot loader，使用uboot这种方案。程序要求也不一样，嵌入式往往就一到几个守护程序持续运行，简单的自启脚本即可，除了像带需要带安装APP支持的智能路由器需要像openwrt这种拥有类PC包管理的之外。 而且他们使用构建结果，安装系统的方式，PC跟嵌入式也不一样，它们需要rootfs尺寸要裁剪非常小，它往往是一个静态的firmware或rootfs镜像，直接刷到嵌入式硬件上的一块静态的固定存储量的ROM上用于承载OS。 因此针对嵌入式的构建，这些支持往往分别分散在各个厂商的手中。 —— 所以，如果有各种嵌入平台，还要考虑进coreboot as 开源firmware，，为什么不把for pc,for embededs，for rootfs,for firmware编译和安装统一考虑进这个综合构建呢？ —— 只是，因为这里面的要处理的工作和复杂度实在太高太大量（这已经是制作一个linux发行版，甚至硬件的工程量了），难于用一个框架来述说。你看LFS就需要一本书。这套构建工作最好是自动化的。要用一套脚本来处理的话就最好了。 —— 幸好，build firmware和build root其实是一个很相近的过程，都是从交叉编译工具的构建和驱动开始， (其实，区分这二者也很简单。一个是硬盘上的OS，一个是没进入OS之前的那个硬件初始化（firmware）中的OS)。这二者统一，自然而然。 市面上终于也出现有这类工具，Cross-ng和Build root，OpenEmbedded,openwrt，就是这样的工具/环镜。如cross-ng只处理交叉构建，buildroot就是整合toolchain（它也可以使用external toolchain built from cross-ng）,kernel,bb,rootfs,libs的工具,只限于直到生成打包的文件系统。不往发行版本一步，coreboot,firmware的OS，buildroot有点像coreboot as buildrom，。openembeded可以直接用来构建发行版。openwrt也跟openembeded一样生成发行版不过它大都针对路由器。 这里面最大的好处是，1，当这类工具统一在同一套脚本上，它可以实现all in one,self contained，所有的部件保持同一风味，比如linuxkernel,bb是同flavor的，它们使用kconfig，且将编译过程中所有涉及到的大件都menuconfig化，如果libc也可以，coreboot也可以，不是更好么。在build root内部就是这样做的，它增加了glibc-menuconfig,linux-menuconfig这样的东西。使得脚本更统一，更in flavor。2，both for embed and pc,buildroot本来就是for嵌入式的，像build root同时支持了ublic和glibc库和各种mainboards,cpu。这样就给了我们融合多套硬件制作同一套软件镜像上的统一构建用的codebase,，而coreboot也是for 嵌入式的，我们看到其soc下有很多欠入式,广大嵌入式的构建工作更应应用coreboot的统一设计而不是分散厂商的。— 这些可以用同一套codebase生成融合硬件使用的镜像不好么？。3，可以统一使用，其写好的firmware可以在虚拟机中，如qemu中测试（qemu因此也是firmware和build root眼中的一种抽象主板）。Qemu可以单独喂给一个firmware,也可以同时结合喂给一个firmware+OS的组合。4,可以统一让融合硬件使用同一个codebase，谈到硬件融合，我们前面有很多例子，虚拟appliance+一个有融合作用的HOST as shell也可以解决硬件融合的很多事情，比如PD的融合模式，而现在，像一些激进的硬进如purism,librem(一个可以发展装有linux的手机。类ubuntu touch一体手机电脑融合OS的硬件产品)都ship了Coreboot 带着这些观点，我们来研究build root和coreboot的脚本 其中的所有原理，都是我们在《基于虚拟机的devops套件及把dbcolinux导出为虚拟机和docker格式》曾手动自建交叉环境和编译之后kernel,bb，libs,所涉及到的那些，Coreboot和Buildroot的编译都能在一台unix派生系的host上完成，要求host上一个toolchain加少量必要的库就差不多了。因为它们都面向构建基础套件。 Build root Buildroot可以在本机上直接构建，官网提到GCC要4.4以上，HOST要用常见unix派生系os。。当然最新发布的buildroot已经用上了vagrant虚拟机，这样就省了好多工作(如果要在host手动安装编译需要的东西，参见那个vagrantfile中要安装的包即可，)。 我们仅讲解自动的。在vagrant中，我们发现最新的buildroot都使用到gcc7来编译了。buildroot(2019.8)大约有10000多个package(实现一个发行版直接可以拿来作为仓库),每个package下面都有.mk和.config.in，package源码都是一次编译即时下载到src/dl的。你也可以make source把它引用的packages源码下好，里面有board/qumu,生成的output中，output/中良好排序着交叉三元组：build, target, host中的临时文件，还有我们要得到的最终的东西，images，可以对比《基于虚拟机的devops套件及把dbcolinux导出为虚拟机和docker格式》来理解和使用。 这里需要搞清build root涉及到的devops工具的关系和区别： vagrant和packer都是hashicorp的Devops七件套之一。packer是提供一个初始镜像，控制虚拟机如VB，PD（我们讲过PD和VMWARE方面的例子），自动化输入。inplace生成新镜像。vagrant是命令行版本的虚拟机管理器。它可以管理VB，PD等（provoders），如果有可用镜像box，可在vagrant配置文件中写明，然后用vagrant up起来给任何一个provider使用，up后可在虚拟机内干任何事情，关机后不导出镜像 它们的关系才是它们的重点，1，用packer也可以制作vagrant使用的镜像。2，Vagrant技术原理它跟packer差不多，里面也有provisioner等等。也是控制虚拟机，也有自动输入和配置文件，只是表现形式产出结果不一样。3，它们共享很多其它机制，如都可以在host/guest间用nat，Nat方式也可以在本地搭建一个也有http sharing。只是配置文件内的写法大同小异。下面来谈在vagrant guest os中使用host的VPN。比如我的VPN在HOST的127.0.0.1:1087端口,虚拟机里面的是不可能获得本地vpn的，所以我们需要在vagrant files中。加一句。export http_proxy=http://10.0.2.2:1087;export https_proxy=http://10.0.2.2:1087;因为用的是nat 网络。 加在这个位置:config.vm.provision 'shell', privileged: true, inline:"export http_proxy=http://10.0.2.2:1087;export https_proxy=http://10.0.2.2:1087sed -i 's|deb http://us.archive.ubuntu.com/ubuntu/|deb mirror://mirrors.ubuntu.com/mirrors.txt|g' >>/etc/apt/sources.list...config.vm.provision 'shell', privileged: false 如果不在vagrant虚拟机中开启VPN支持。可能会卡在Downloading and extracting buildroot 2019.08不动。这其实也是从前文《packer中学到的》，，可在打开的虚拟机窗口中测试box os用户名密码都是vagrant，ifconfig看到，在本机是访问不到nat内部的不能ssh vagrant@10.0.2.15。 Build Coreboot Coreboot最新版是coreboot-4.10,使用linux kernel式的kconfig，和bb式的可视裁剪配置。所以它跟build root是flavor的，也对qemu有board支持。。跟buildroot的职责一样，完全对引导期，进入OS前的firmware OS的构建。 Coreboot并没有使用vagrant，你得在一台HOST上配置再编译。也是配置toolchain(因为稍后Qemu x86，所以用any toolchain)，mainboard那些，不同的有payload，对于mainboard，如果是测试，可以完全选择使用Qemu 模拟x86. 之后make一路通过。 我们的改变 如何集成到我们的cohdevbox srctree中。及你们的工程中。 上面提到vagrant和packer同基础，工作方式和配置都大同小异，在我们现在的实践文章中，都是用的packer，那么为什么不能把vagrant当packer用呢。Vagrant还可以避免出现packer那种一旦失败，全部从0重来的尴尬。即，在Vagrant退出按ctrlc,再重新执行up，它会重用上次grant provision的结果(因为它是虚拟机嘛)。这跟packer不一样，packer的构建不会重用上次provision的结果，会重新构建。虽然它不产生镜像（实际上那个镜像就是你的provider在你硬盘上的镜像，关机复制得到和packer一样的结果）。 我们会在srctree中提供一份编好的tinycorelinux硬盘镜像作为vagrant用的box。然后整个源码会deprecated packer。只用vagrant.然后在其中通过配置文件手动编译avatt，结合修改，代替现在的cohdevbox srctree。 最后，我们可能全程用qemu作虚拟机，因为qemu支持命令行提供firmware，它可以统一测试firmware和rootfs，完全可以用qemu来替换VirtualBox，qemu是命令行虚拟机工具。与其他的虚拟化程序如 VirtualBox 和 VMware 不同, qemu可以模拟CPU(全虚拟)，甚至喂给firmware。但vb,pd都不可以。还有一点，QEMU不提供管理虚拟机的GUI（运行虚拟机时出现的窗口除外），也不提供创建具有已保存设置的持久虚拟机的方法。除非您已创建自定义脚本以启动虚拟机，否则必须在每次启动时在命令行上指定运行虚拟机的所有参数。 我们选用的host平台是osx,不能用到kvm/qemu,因为kvm是linux的。在osx上我们不打算用到任何加速方案（半虚拟）。因为是测试。直接使用qemu默认的console窗口而不使用任何GUI管理器，vagrant可以通过libvirt用上qemu。 注意到coreboot编译GCC toolchain等输出信息很精简。而我们在《packer》文中不能控制选择过程warning等信息。所以决定研究后采用。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
Dsm as deepin mate(2)：在阿里云上真正实现单盘安装运行skynas
本文关键字：单盘群晖，本验证码版黑群 在《使用群晖作mineportalbox》文3和《利用整块化自启镜像实现黑群在单盘位实机与云主机上的安装启动》，及《dsm as deepin mate》文1中，我们着重提到使skynas在云主机上单机安装使用的方法，这些文章中，研究点经历了从“黑群webassit，从0开始安装的方法”到“从镜像开始，能启动就行”的路径变化，但这二者我们都没有完全完成，达成最终目的。下面继续这个课题，实现最终在阿里云上单盘安装运行skynas。 制造并导出镜像的方法 我们重新开始，首先去阿里云开一台系统盘20G，数据盘20G，镜像为skynas615-15254的按量机器，等进去了（因为我们不尝试导出纯净可安装镜像，所以这里不必跟以前一样等一启动就急停，做快照…，或者使用阿里云最新的卸载系统盘功能,恢复系统盘初始状态不重启…，其实这个时候导出的镜像也没用，会失效，稍后会讲到），新建一个admin，密码自设，这个admin会是管理员。我们发现应用只有系统区的二个,filestation和universal search，没有关系，打开控制面板，外部访问中的ssh，我们可以ssh admin@yourip从命令行用admin登录，然后sudo synouser --setpw root xxx，然后exit或su root切换到root。 其它的应用去http://synology.cn/zh-cn/support/download/VirtualDSM#packages复制其spk地址。通过命令行cd到/tmp，wget这个spk，通过synopkg install xxx.spk来安装，这种方式下你需要自己探寻app的依赖关系。启动失败一般是依赖没安好。 但是我们这里并不急着安装APP，因为我们优先考虑尽早把系统设置保存下来，这些将来用于作为模板初始化新volume， ——— 系统启动，安装APP会在数据盘volume1中产生文件，分析产生的文件有volume1/@appstore,volume1/@databases,/tmp，volume1/@tmp，这些文件与APP与系统本身都绑定，如果不打包打走，等volume1被释放，这些APP或系统本身，在新volume上启动，运行都会产生设定丢失或权限隐患等问题。比如tmp中包含有系统关于volume1的空间设定（这个设定会让没有任何volume的系统在启动时误认为volume1损毁，但这正是我们需要的,在以前的文章中，我们那个tmpdata,tmproot只是安装/升级时解包的逻辑。并不是进入系统后判断用作数据盘的逻辑。），相应的，@appstore应该就是app的数据。—— 为了不使这个模板文件过大，也是为了不带入因集成APP产生的不确定因素，我们不必事先在这个20G的数据盘volume上装太多APP，后面在增强部分会讲到APP。 我们打包这些初始设置文件并替换volume所在盘：/volume1/@database/pgsql(它实际上/var/services/pgsql,app和系统都会使用它)/volume1/@tmp（它实际上是/var/services/tmp,app和系统都会使用它）/tmp（这个目录极为重要，系统使用）cd到/，tar cvpzf template.gz tmp volume1/@tmp volume1/@databases，带原用户权限打包，这样这个模板文件就有了。 事实上，在这里我们就可以把镜像导出来了。因为此时群晖是视数据盘为volume1的，我们盘和模板都有了，所以将在下一次重启时永久卸载这个volume1，让它用上新volume就行了。 来测试一下：1，制造新volume。因为群晖中有parted，比起fdisk它是即时生效的，所以sudo parted /dev/sda mkpart primary 4 100%，然后格式化sudo mkfs.btrfs /dev/sda4，完成。2，sudo reboot 重启，在阿里云ECS的存储管理中，卸载volume1，重启进来，登录web端。空间管理器提示没有任何存储，这是意料之中的，那么没有什么也没有提示空间损毁呢，这是因为tmp是每次启动都会清空的，保存在其中的空间信息会丢掉。3，我们把template.gz恢复到tmp，web端存储管理器立刻提示空间损毁，这是与原来数据盘volume1的挂钩的tmp/space数据，这个时候我们只需要把/dev/sda4挂载到/volume1就可以了。我们在命令行中尝试root登录，sudo mount /dev/sda4 /volume1挂载，web端已显示存储空间可用，这里其实格式sda4为Ext4也可以直接挂载。 然后你就可以导出这个自动镜像为别的机器所用。导出时可以在线nc导出(需配合virtio tinycorelinux，因为群晖没有nc也不能在其中直接nc):1，dd if=/dev/vda | gzip -c | nc -v -l -p 5000 , 恢复处用nc -v xxx.xxx.xxx.xxx(这里最好使用阿里云内网地址) 5000 | gzip -dc | dd of=/dev/vda，也可以2:保存为一个本地gz的方式然后使用ossutil+oss内部endpoint地址导出或者scp xx.gz root@xxx.com:/var/www上传到一个远程空间，oss最快。 恢复到不同的机器时，需要手动产生sda4及重复上述测试过程（使用非custom linux镜像如果是custom linux，需要配合virtio tinycorelinux修改/boot/aliyun_image/os.conf），1，wget -qO- http://xxx/vdaimg.gz（配合oss内网endpoint和virtio tinycorelinux） | dd of=/dev/vda 或者2用InstallNET.sh -dd，重新测试前，记得把网络改了，你需要改，etc/sysconfig/network，etc/sysconfig/network-scripts，/etc/resolv.conf，并增加一条gateway：route add default gw xxx.xxx.xxx.xxx。 增强：在镜像中直接封装sda4 as volume1，及提前封装app 事实上，我们可以对镜像进行一些强化，因为上述过程在每一次换机或重启都要进行一次，为了追求制造一个自动的镜像。我们需要自动产生坏盘和自动挂载sda4，但又不能直接把这个sda4封装进去(因为这样在不同机器上不能自动扩展空间)，所以还需要一些内容 自动产生损毁盘。自动产生并挂载sda4要echo 自动挂载规则到fstab。这就需要绕开syno的自动cfgen，重命名/usr/syno/cfgen/s00_synocheckfstab to k00_synocheckfstab这样etc/fstab就不会改了。如果不存在sda4,sudo parted /dev/sda mkpart primary 4 100%，然后格式化sudo mkfs.btrfs /dev/sda4然后sudo vi /etc/rc,在开头加上：echo “/dev/sdb4 /volume1 btrfs nospace_cache,synoacl,relatime 0 0” > /etc/fstabmount -a如果不存在/tmp/space,volume1/@databases,volume1/@tmp，则tar zxvf /template.gz -C /如果是ext4，直接在/etc/rc开头挂载mount /dev/sda4 /volume1，即可,mount -a不用加 进一步封装App，你可以手动将APP移到系统区：先停止app，这里以TextEdtior为例，先sudo synopkg stop TextEditor，然后sudo mv /volume1/@appstore/TextEditor /usr/local/packages/@appstore，再然后sudo ln -sfn /usr/local/packages/@appstore/TextEditor /var/packages/TextEditor/target 但最好是直接安装app到volume1做app封装，因为app启动与volume1/@tmp,volume1/@databases相关,直接转移到系统分区的APP绝大多数不依赖有没有一个volume1，但有些会要求有volume1，这时即使有原来的volume1/@tmp,@databases，启动也会出错。另外注意，把所有的依赖和核心安装全： 这里我总结了spk的依赖规律。一些语言类的：PHP5.6-x86_64-5.6.40-0059.spk(webstation需要，nginx是系统自带的)PHP7.0-x86_64-7.0.33-0028.spk(photostation需要)Perl-x86_64-5.24.0-0074.spk,PythonModule-x86_64-0114.spk(perl和pymodule cardavserver需要,py2是系统内置的)，Node.js_v8-x86_64-8.9.4-0005.spk(这个就是chat server缺失的v8,calendar也需要)PHP7.2-x86_64-7.2.24-0006.spk(这个calendar也需要)和基础类的：SynologyApplicationService-x86_64-1.6.2-0431.spk(calendar也需要)的都是最好要安装的。然后就是各种其它APP了。 本地验证版 还记得开头说的“其实这个时候导出的镜像也没用，会失效”吗？上一步导出的镜像有可能失效。在另外的机器上启动时会出现仅加载到webassit的情况，这应该是群晖的验证过程。但是我测试时从一台新阿里云+skynas的按量组合产生的镜像，在24小时之内是不会的。所以要赶在你做好镜像的24小时内”食用“这个镜像，很沮丧是吗?我们可以把黑群弄成纯粹的本地验证。 验证的过程肯定存在于rd.gz，rd.gz相当于usb pe(它会把绑定的网卡或sn与官方比对？异或是上面的tmp?)。而且我发现，普通群晖与skynas的rd.gz中的逻辑脚本组织等，都很接近。skynas的rd.gz并没有经过深度定制。只是没找到vda变sda的地方。是否可以直接相互置换制造云上的黑群？测试安装普通黑群到阿里云， 但是安装好了的，绝对没事(这分二个过程,验证的过程永远在sda1中，而不是sda5中)，不然，安装好了的syno会重启后boot不动，这是毁灭性的。没有出现过黑群被删volume1。 一些本质上的问题,任何黑群晖都不是绝对的本地验证版 就像微软假sn一样，你固然可以在淘宝上买到，但如果涉及到使用某些在线服务时（比如黑苹果之于icloud，黑群晖之于quickconnect，windows之于office，共同的在线升级等），注册在官方的库中，还是可以被辨别并删掉中止服务的，一切只>> 是官方出于某些目的并没有去针对反破解，这些反破解措施中有没有包括删掉你的数据不可得知。技术上可以绕过机器和本地，但是你没法绕过远程和人 — 除非你满足于使用封闭的本地服务，所以，任何使用破解OS这类大件都是有风险的，黑群也是。 —— 读到这里的小伙伴都赢了。让我在这里看到你的头像 接下来还会有一篇文章。Dsm as deepin mate(3)：更安心全面地使用syno as icloud,我们将讲解app中那些关于个人办公及日常使用的portal,erp性质的app（email,cardav,calendar,etc..），探讨其可以无缝代替iCloud的方式，如何利用cloudstation+cloudsync作三地异地，探讨其同步算法与原理。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
Boot界的”开源os“ : coreboot，及再谈云OS和本地OS统一装机的融合
本文关键字:firmware as service, linux as boot，，boot as infrastructure，real cloud os and app，云操作系统选型，实机装机/裸金属通用的云OS。hypervisor/vm通用的云OS。 Firmware编程是计算机（软件）编程的最初一种形式，也是OS的雏形。没错，它是针对硬件的”软件“编程。这个层面最初形成了我们看到的OS。最明显的层面就是OS中的HAL层面。 历史上。bios是这个规范，如今，UEFI，各种各样复杂的loader也出现了。甚至还有linux as loader，即把linux作为开机出厂程序。用户装的OS作为第二级OS。 那么这种情况合理吗？其实所谓UEFI只是机器引导之后的一个特殊执行体而已，这个执行体在没有进入OS之前，可以是其它任何软件。甚至一个极简的linux rootfs。所以，loader as uefi跟loader as linux没有任何区别-它们共享一个相同的最基础部分:就是那个机器引导，之后同质之前同源。 这样有什么好处吗？我们知道UEFI中有很多驱动。UEFI的作用就在firmware中提出一种新的地址模式和能够使用现代语言的编程方式来处理硬件的改变。可是，这不只越来越复杂的UEFI能办到。在一种现代OS中这样的东西中也能办到，而且天然就是现成的，不用重造轮子。比如linux，它类UEFI本身就是高级语言的地址空间产物，它的宏内核设计使得它的驱动天生就是内含的。其中的很多drivers也不用在UEFI中重写呢。而且它够小。它作为一级主板预置程序可以发挥像WINPE，LINUXPE,syno web assist,osx recovery一样的作用，而且，除此之外，os还能兼能提供现成的工具，如busybox等。这样，linux loader既是recovery，也是firmware.等等，它还有其它作用（稍后就说到） 为什么会有这种需要和改变呢？这种需要的出现是因为cloud computering出现了。它要求对现有的PC，裸金属机器。进行新的一轮upwards streaming抽象。使OS的概念重新分层分级，包含单机，实现，云主机，各种寄宿有OS的地方 —— 形成一种多用的云OS，既然这样，何妨让Cloud Computing也配一个抽象Firmware不就好了么。。 所有会有我们今天谈到的firmware as serice，coreboot就是相关的产品。 Coreboot：抽象firmware as serice,云host os 它的前身是linuxbios，不过后来变成了现在的coreboot,libreboot是它的一个极力去除闭源驱动的开源版本。 coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a payload. With this separation of hardware initialization and later boot logic, coreboot can scale from specialized applications run directly from firmware, operating systems in flash, and custom bootloaders to implementations of firmware standards like PCBIOS and EFI without having to carry features not necessary in the target application, reducing the amount of code and flash space required. 记得当时刷chromebook用的就是这个coreboot。它对各种设备，包括云主机都有payloads. 而linux as payload更有趣。 Two aspects emphasized by proponents of Linux-as-a-payload are the availability of well-tested, battle-hardened drivers (as compared to firmware project drivers that often reinvent the wheel) and the ability to define boot policy with familiar tools, no matter if those are shell scripts or compiled userland programs written in C, Go or other programming languages. 所以，接上面“稍后就说到”：它不光是advanced firmware, recovery，还可以做虚拟机管理器，这样买来的预置了linuxbios的机器永远不怕坏了。因为可以在其中安装多OS。而且这些OS是linuxbios的二级OS，它们是用户OS。只是一些类似虚拟机guest os的主机（所有的guest都是平等的，而且可以parallel booting）。Splashtop产品就是这样的一种设备。Avatt:all virtual all the time就是基于coreboot，在linux里提供了ovz, kvm虚拟机管理器，可以允许客户安装自己免坏的OS，类似exsi，但是可以作为日常用机而不是服务器。———— 当然，这种firmware是需要刷机的。 而正是这个虚拟机管理器功能，就带来了一个更为巨大的意义：——— 我们一直知道，虚拟机，虚拟OS，虚拟化是云计算的主要概念和手段，虚拟机的运用放在今天实在太重要了，因为它不但是装机/运维问题，开发/devops问题，virtual appliance/appcontainer问题，也是云计算和云开发的基础课题。云主机一般是虚拟机。但实机，自从coreboot它使得本地也可以更方便地云化，从此也可以通过虚拟机装机。而不必仅限于传统的host内使用guestOS的方式和结构。—— 作为一种从最开始处：从类传统PC的BOOT处，对云OS装配firmware，的”OS”，它已经天然是个“实机云HOST OS”了。 unikernel和云guest OS 那么guest os呢？还要有unikernel+guest os的设计。 什么是guest os，就是我们通过云在其中运行应用的那类OS，宠统来讲，我们最常接确到的“云OS”而不是什么hyperior，其实我们之前文章一直在探讨，什么是云OS，在不同的层次上，有很多OS，甚至APP都称自己为云OS。 比如，对于装机和开发，在谈群晖的系列文章中时，我们谈到docker as devops，qnap的qvpc，群晖是一种云OS，对于云APP，lamp是一种云OS(with appstacks)，cloudwall是一种云OS (with db and sync only)，Tumblr 它也是一种云OS，因为它提供了一个聚合功能。 所以我们最后结结实实地总结得过一句:云OS从来没有自己的专用OS，云APP也没有本质上专用的云APP。都是现在的本地OS和本地APP的分布式的叠加。所有这一切，都造成了抽象的过度堆彻。 那么现是在思考解决这样问题的时候了。拿webos来说，Webapp,webappstack虽然是打洞主义，然而它的碎片化特征却是独一无二的（超链本身就是一种碎片化,webapp是page,是applet，非常碎片化，通过超链的表现相连）。现在，OS的分布化和碎片化也要发展起来了。 基本的思路就在这里，基本的解决问题的产品就是unikernel。将OS也像APP一样碎片化。就有了我们即将谈到的云OS（关于云APP。也有碎片化的云APP）。而unikernel。它对传统OS也进行了裁剪和重抽象，它也通过碎片化解决了抽象的过度堆彻。 Unikernels are single address space library operating systems. An application compiled into a unikernel only has the required functionality of the kernel and nothing else. Such a stripped-down kernel makes unikernels extremely lightweight, both in terms of image size and memory footprint, and also can lead to security benefits due to a reduced attack surface. There are many such lightweight unikernel implementations, e.g, LING, IncludeOS, and MirageOS. LING’s website takes 25 MB of memory because it runs on top of the LING unikernel. IncludeOS’s base VM starts at 1MB and a DNS server running on MirageOS compiles into a 449 KB image. （others : 容器OSCore os, smart os,vOS, etc..） Unikernel往往去掉了传统OS kernel中的某些hal部分。因为它是hyperior的和hostos的。而且它形成了一个操作系统配一个进程的构架。 而其实，一个操作系统一个进程，内核和应用都在一个地址空间内。一个APP配一个OS，是云计算中理想的Guest OS。这有点像user mode linux和colinux,这样的一套OS+APP就形成一个Virtual Appliance，谈到appliance，这是虚拟化自己的APPMODEL，类似web的web app,native的native app,mobile的mobileapp，virtual appliance最初的形式是vmlite的是appliance，Microsoft vpc的xp融合模式，就是不透出guest os，OS作为守护，仅把融合在host os的app透出来。—— 所以，它是对virtual appliance的增强。 Unikernel也是对容器和容器OS的强化。也是真正的applvl的虚拟化。见《打造一个Applevel虚拟化，内置plan9的rootfs:goblin（1） 》。因为它不是用容器管理器的方案来处理host/guest关系的，而是实在的把OS包含其中。 也是对appmodel的增强，一个APP配一个OS，就没有了server, 它是对servless app的增加。 可以说，配有coreboot的云主机+配有unikernel的guest os，是包含了对云OS装机， devops,applicance 容器。的4 in 1所有路径上的解决方案了。 —— 无论如何，以后统一用虚拟机装实机/虚拟机，云主机，开发，作容器，的梦想可以融合了，可以实现了。这是我们前面诸多文章的目标。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
阿里云上利用virtiope+colinux实现linux系统盘动态无损多分区
本文关键字：利用colinx+virtio winpe定制aliyun多分区linux系统盘,在winpe xp winpe中运行colinux,在windows pe下真正操作linux分区，利用colinux作单硬盘分区扩容无损分区， bootice安装grub2-00 到硬盘,云主机越狱装自定义镜像 在《发表virtiope》《在阿里云上装自定义ISO》和《定制virtio winpe镜像》系列中，我们用类似手机越狱，刷机的hacker workarounds（围绕virtio pe为中心,利用一系列小工具组合）的方式达到了使云主机装机变得像本地PC一样方便流行的维护/管理方式，，那里我们侧重讲解的是windows，任务结果是将自定义ISO装成了系统盘，将系统盘分成二个区并把备份后的镜像装在第二个区内，这样借助virtiope和一系统一数据区的双分区设置可以恢复一个全新的系统。 在《一个设想：共盘文件系统的windows,linux》一文中提到过windows与linux二大OS文件系统存在巨大鸿沟的现状，及我们希望得到一个共盘的uniform windows linux fs的要求。本文中，我们将在装机领域，探索一种“在winpe下自由操作linux分区”的目标与可能。----- 文章最后，探索为单硬盘单分区下的云主机linux分裂为二个分区，打造一个类PC和手机recovery的可恢复rom机制，只要这样，在装机和实用阶段，都能完成某种“共盘，实用的windows,linux融合方案”，那文提到的设想才能基本变得“像那么回事”，也算有技术参考方向。 在winpe下操作linux分区的难点，在于它不如ntfs受windows中的磁盘工具如diskgen,pqmaigc之类与其结合支持得好，在windows下用此类工具操作EXT3，要么不受支持（需要特定驱动且这类驱动往往很原始），要么能读不能写ext分区，要么能写但是频频蓝屏，更别说动态对其调大小，与类gho方式恢复镜像等（diskgen493开始支持格式化EXT3，也不行，稍后会讲到）。甚至格式化都很久 关于单分区linux动态扩展出新分区有LVM这样的方案，但是要求在业已分好标识为8e的分区格式的情况下进行。 我们的总目标，还要打造一个windows,linux二合一的pe维护盘(保证一切在该xp based winpe下完全，且不需要二次进不同的ISO环境，比如合盘的windows+linux pe)。这一切我们将在1g内存的阿里云预装了ubuntu14.04 32bit的一台机器上完成。下面开始： 在阿里云上利用noimagecolinux实现linux系统盘的动态分区扩容 这里我们额外用到的virtiope工具有（除了原来封装于virtiope的四个:showdriver,ext234reader,bootice,ramdisk），还有：winpm 7 服务器版本for winpe，它用来分出新ext3区。，还有colinux noimage（busybox我们能用到的工具有mount,tar,cp等等）用来重建系统：众所周知colinux，根据我的《发表colinux》，它被定位于guestos，可是它本身也是工具，colinux可以nomiage的配置形式运行，可加载windows目录为分区也可加载本地硬盘为分区。不加载任何镜像的colinux自带busybox，可以实现在windows下操作linux硬盘分区，实现真正的重新格式化，分区，扩容等效果。最后还需要从网上找一份新grub boot文件包,用来重建grub2.0。 1)准备工作，按照《在阿里云上自定义安装iso》的原系统是linux情况下的方法，将以上几个工具和boot文件包上传放到boot/tools下，然后tar整个根目录 cd / tar -cvpzf backup.tar.gz --exclude=/backup.tar.gz --one-file-system / 看到打包后的大小是570m，这个就是原系统镜像。 2)然后，启动进入virtiope，利用ramdisk建立一个590m的内存盘(size=0000250 hex)。利用234extreader将/boot/tools和backup.tar.gz放进来这里的暂存盘是T：(为了操作234extreader你最好要有一个带右键菜单的键盘)，利用winpm删除整个40G分区然后分二个小ext3分区，一个10G用来作新的系统盘，其它30G用作自由空间日后作数据和镜像存放。打开colinux conf文件夹，noimage.conf中设置如下： cobd0="\Device\Harddisk0\Partition1" cofs0="..\..\..\" (因为tools与backup.tar.gz并列放在T:中，回退3级才能看到T盘根) 保持mem=128，方便稍后的复制解压，也不能开得过大，因为1G的内存开了用得差不多了 现在portable_colinux.bat打开，提示enter激活busybox时，mount 2个盘到noimage colinux： mount /dev/cobd0 /mnt/temp (10g盘) mount -t cofs 0 /mnt/win (注意cofs与0中间有个空格) (以上2个mnt点是colinux自带的) 3)然后，就是利用busybox中的工具： cp mnt/win/backup.tar.gz mnt/temp/backup.tar.gz chdir mnt/temp tar -xvpzf backup.tar.gz -C / --numeric-owner 解压 用bootice安装新的mbr grub2.0到硬盘，从网上下载grub的boot文件包替换现有的boot文件夹（除了保留boot下原有的10个内核文件）。 4)，最后重启，进入分区调整后的linux。 如果看到新的grub2启动界面，就说明基本要完成了 set root=(hd0,msdos1) linux /boot/vmlinuz-4.4.0-85-generic ro root=/dev/vda1 （注意阿里云是vda） initrd /initrd.img boot 进入新的系统，成功！！ 打造linux和windows二合一的winpe装机维护方案 一些失败的尝试： 我曾尝试7zip直接解压或gnu windows tar解压到ext2sd形成的分区中，但都会蓝屏，这就是为什么我开头就说windows下处理linux分区是非原生的。大部分时间它只是辅助用一下。据说比ext2sd,ext2ifs更好的是Paragon_ExtFS之类，但是上传后无法运行，也无心去试了。不过(要是virtiope日后直接集成了ext2sd就不用这步了)这倒是另外一个极好的尝试方向. 我也曾试过diskgen是4.9.3的（4.9.3的开始支持对ext2/3的分区，它虽然比较大，但是它综合了bootice,234extreader的全部，且鼠标操作好。），跟上面一样它们甚至在xp winpe上无法运行。只有这个winpm 7 服务器版本for winpe很好支持手标操作。 我曾试过mount -t tmpfs -o size=590m tmpfs /mnt/tmp，内部fdisk,直接DD，等等，都不够直观或根本行不通。 其余，就可以不断发挥了吧。比如，前面还有《我们有第二开源操作系统吗》和《一个设想：共盘windows,linux中》，后来我们还提到了《reactos可用版》《colinux as xaas》等等，如果说这篇文章是装机领域的这类使linux,windows天然融合的努力，那么那四篇文章纯粹是是实用领域的融合windows,linux的尝试。 恩恩写够多了，就这样了 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
把群晖mineportalbox当mydockerbox和snippter空间用
本文关键字：把群晖当真正产品级的mydockerbox用,利用docker hook dir as volume在群晖上制造snippter空间 虽然在前面的《群晖docker上装ellie》和更前面一些文章中我诟病过docker aufs的诸多弊端，但不可否认的是，docker这种能虚拟user mode OS能虚拟application的机制能成为开发和部署的利器，比如结合git server webhook能构建出dockerhub这样的自动构建/发布平台（除了开发，部署，甚至于dbcolinux中我用openvz模拟其用于“装机”），windows 10以后也把windows2016中的docker技术应用到了桌面级-从此桌面沙盒程序将一切程序数据和程序文档数据隔离在container内，动态装卸，能在APP级允许程序实现类手机应用的“缓存清理”---当然windows docker也可用于服务性程序。bitnami打包的服务器程序已经基本全部有dockerized版本。。。越来越多的迹象表明，docker这种虚拟化机制还是十分流行和有用的。 其实群晖套件spk就是沙盒原理，群晖在技术上可以仅实现为docker only box，比如它的photostation等都可以实现为docker，变成纯dockerbox用。变成类上面win10+docker支持的hostos+guest all docker化架构，只是它要兼容没有docker支持的机型，所以不便全盘docker化。 好了，现在接《群晖docker上装ellie》，继续讲解未完成的东西，接《使用群晖作mineportalbox（2）：合理且不折腾地把webstation打造成snippter空间》,本文也会讲如何在群晖上把docker打造成又一个snippter空间:而且这个空间也是可以统一像home photostation,home cloudstation一样置入home中的。 在群晖上装ellie docker-compose.yml 群晖6.2的docker是不支持直接安装docker-compose.yml的，只有把minlearn/ellie-corrected和postgresql9.5的镜像先在群晖中下载下来安装，然后先用postgresql镜像开一个容器postgresql1，主机端口不必是5432，但容器端口要是5432，密码环境变量设置一下，volume可以新建一条挂载到主机的home/docker/postgresqldata中，对应docker的/var/lib/postgresql/data，定为rw。这个目录会屏蔽docker中的/var/lib/postgresql/data，因为下一次你使用不同的主机目录把它volume出来到新的主机目录，出来的数据是全新的postgresql给你的模板数据，所以，任何主机目录中的volume对应体，在重新链接或转移时，应该备份一次。 然后，用ellie-corrected镜像开一个容器，按上文加上4000:4000和自定义环境变量SERVER_HOST=your ip。link到新开的postgresql1容器，别名定义database。ellie会启动，等待一会ellie便会连上postgresql，mix ecto-create,migrate,phx.server。等启动完成，创建快捷方式到群晖桌面为群晖的公网IP:4000。点击就可以访问了。ellie-corrected的volume在上文讲到，ellie docker-compose.yml中为ellie-corrected设定的那条volume会不能生效。问题是：你把容器的/app映射到主机上的/apphost，启动ellie后会在日志中显示/app/run.sh执行permission denied，这是因为，1：通过volume postgresql,volume ellie这样的方式mount到主机目录的目录是容器实例运行时，自动屏蔽掉容器端的那个目录的，而使用主机目录的一切的。包括权限。2，像postgresql的volume是不包含任何代码和可执行体的数据路径，所以没有执行权限问题。而ellie中有一个/app/run.sh要执行，要知道，docker内部的权限体和host上执行这些代码的执行体是不一样的。启动时ellie自然会有权限问题。 其实群晖docker默认给docker volume划分的共享文件夹是根目录下的那个docker，在这里建立的docker volume依然会有权限问题。而群晖也没有为docker建立一个统一docker用户，因为各个docker内部的权限都是不一样的---分属各种各样的docker内部os template定义的用户。那么，有没有一种方法，将它转为主机上统一用户，使得docker出来的任何需要权限的目录在主机上都可以通行呢？ 有一个workarounds可以解决，统一把/docker或home/docker中，volume出来的主机目录设为EVERYONE读写权限即可。这样会有安全隐患，但群晖一般都是一台独用的，admin,guest都是被禁用的。所以能保证你当前用户不被破解，安全是可以基本得到保证的。 那么，最终如何实现在主机端访问到ellie /app，像postgresql volume一样使用ellie volume "/apphostdir /app"的方式呢？ 修正ellie所用的/app volume VOLUME这个参数可以透出容器内部目录，当然不用VOLUME参数，在了解容器ROOTFS中存在/app的前提下（这需要用户看过ellie的dockerfile），直接volume出来/app到/corrspondinghostappdir也是一样的，使用VOLUME更能清晰化这种过程和目录(另一种bind mount)。 就如同WORKDIR定义了接下来在dockerfile中的当前目录环境一样，VOLUME也规约了一段dockerfile中上下文中，那些影响各层aufs构建打包过程中，向最终volume定义透露出来的最终aufs叠加层。一个volume指令后面的指令(主要是run影响aufs叠加）会对它上面的volume不产生作用。即，仅对调用volume指令前的那些aufs操作产生的结果有意义。 所以这个 VOLUME /app放在chmod+x /app/run.sh后也会是没有意义的。你可以尝试移动/app/run.sh使之放在docker rootfs的其它地方，自己尝试吧。 好了，通过上述的讲解，你可以通过docker把一切程序用到的data和app数据归纳到home/docker/xxx下。将群晖打造成一个真正产品级的mydockerbox,和各种volume制造成的snippter空间。 关注我。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
比WEB更自然，jupyter用于通用软件开发的创新意义：使任何传统程序秒变WEB
本文关键字：online language,在线语言系统,jupyter,ipython jupyter,在线编译器，在线解释语言,engitor 在《engitor:基于jupyter,一个一体化的语言,IDE及通用分布式架构环境》一文中我们提到，jupyter不止是一个分布式IDE它还是个分布式架构，更准确地说，它使任何使用engitor开发的程序变成WEB架构下的程序，而这个“WEB”，是jupyter webiz之后的web,然而它比web更自然，更强大。 jupyter作为一个极具创新的普通的产品不可忽视性，在于它是一个能改变现有软件开发，发布，甚至教育，用户体验端的东西，使之秒变WEB，做成WEB架构下的该程序版本，正如jupyter主页上提到的interacting computing，利用这二字官方强调的重点还主要在这：可用于编程=可用于开发布署=可用于定义一个appmodel，也就是利用jupyter可以达成一个计算。这个计算就是WEB化。 因为jupyter system实际上是作为一个一体化的多语言开发测试部件live code,debug+demolet show engine和ide,meta container环境。而存在的。有点拗口？ 第一，它增强了分级容器的范畴。使程序接上WEB式的组件开发环境，以及UGC支持。 普通的容器就是PAAS，RUNTIME AAS，像gae这样的东西，lamp这样的东西，在ipynb面前只是基础建设。前者没有细化到具体应用级，是从云服务到语言服务到语言框架服务的分级细化过程，提供服务的厂商只能算是ISP。而后者可以做到应用生态内部。为具体应用定义一个由.ipynb 组成的demolet定义的容器环境。 jupyter将应用接上了一个任意式的demolet容器，如果说传统分布式方案是从云服务到语言服务到语言框架服务的分级细化过程，那么jupyter就是直接具体应用分布式。 jupyter是langsys as distributed srv,langsrv,这跟容器/applicationsrv —- 语言库api as services 不同，它更适用当前者完成了之后，要将容器运用到具体应用层之后的情形， PS：语言即库，库即API，API即组件。始终要记得可复用件在编程史上的演化（特别是其与平台，语言系统结合，脱离语言系统后变成分布式可开发复用件之后那些形态），可复用件必定存在一个容器或hosting backend.接下来谈到的分布式API也是如此。 第二，它增强的是WEB等分布式API，从程序的开发发布方式变成类WEB的分布式架构。 分布式架构要纳入被开发，首先要API。程序的最上层无非开发发布，最原始的开发件叫API，最原始的部署件叫库，传统WEB和桌面分布下，都有自己的方案。从本地组件到到分布式组件，到接口到服务性API，到脚本（甚至开发件和部署件在脚本环境下最终做到了统一，这就是组件,demo即api，能在语言环境下动态运行services方式被识别为api的，都是组件），都要跨网络和socket这层。WEB是直接整合HTTP。更通用的WEB是退一步将HTTP换成了websocket，可是于任何方案将API做成分布式，都免不了要解决网络这一层。 jupyter的架构最上层CS二端用消息通讯，消息是文本化的协议表示。更接近语言处理支持需要和持久化定义需要。比如json,xml-rpc,soap就是用对象化的方式来持久表示协议的方案。 jupyter基于消息，可用于BS，CS，它免HTTP是一种比HTTP WEB还要通用的通用分布式CS协议。是另一种websocket之类的等价品。它使纯粹一体化的CS式WEB变得可能，即jupyter WEB（jupyter console,qtconsole as common jupyter app based appbroswer）。甚至不用到websocket和jupyter notebook时免传统浏览器。 第三，它增强了WEB等综合通用分布式APP的范畴，使任意程序变成page based applets。 这里的APP用来指终端程序（VS库框架等），用jupyter来构建WEB，代码和运行可维持only in a page unit…发行单元以一体化的ipynb page(含界面+逻辑一体化不再是分散的html+服务端处理脚本)为单元。是富文本界面（js+.ipynb needed)和渲染过程的传统WEB界面的等价品。而且，天然CS，no bs式的web可分离部署是个巨大优点（ 有时候省事做站要求我们将逻辑后端和界面大量静态资源的前端分开部署）。 综合一，二，三，api的发行直接源于语言系统并如一所讲提供了由任何.ipynb demolet组成的容器环境，能采用WEB开发架构且脱离浏览器的分布式程序，这已经是个“通用分布式”的WEB环境了，于此，jupyter做到并增强了WEB。能将任务jupyter支持下的语言系统的任何程序变成WEB架构。 一切的一切，是对于分布式架构开发部署来说，jupyter的断层和抽象切入面是：从语言层就集成cs和WEB支持就开始将自己化身为langsys based srv that micmicing a websrv，，所以免bs.免分布式API..软件界伟大抽象的二大特点，一是选择正确的粒度选择，另一个就是jupyter聪明的断层，从精巧的切入面去正确的断层抽象。当然这可能是jupyter设计者没想到的而我只是个事后诸葛而已。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
-
发表了文章 2020-09-28
编程实践选型通史：平坦无架构APP开发支持与充分batteryincluded的微实践设施
关键字：自带paas语言系统,自带组件,自带用户工具语言系统，一元下的多元，初学者第一门实践语言选型 在编程实践选型上，往往涉及到来自语言，应用，工具，人（又分多种角色）多个方面的影响，需要处理多个现有生态异化矛盾和处理已有实现之间的差距，甚至出现需要重新发明语言等基础设施间的轮子的情况都时有发生，是一个格局需要放大到软件工程方方面面的过程。—–一言以概之：软件工程，——-其实，大凡考虑进所有事情并最终处理涉及到人端的那些方面的事情都能称为工程，可见其大和复杂，这也是为什么很多图省事的方案企图提出一个“one for all”终极方案的原由所在。这个“one”往往可能被实现为开发上来讲的一种/多种语言系统，一个包含语言修正/强化的framework（如qt），一个工具，一套问题域解法，一套敏捷方法，等等，当然更有可能是它们的综合 —- 公司或个人将他们做成自己的codebase用于持久复用以应付统一选型。。 在《1ddlang选型》一文中归纳的是以前1-4种旧的纯粹语言选型方向的“one for all”讨论—lddlang也就是某种1ddcodebase，在那里我们主要聚集语言内部特性。本文作为《1ddlang选型》，《语言选型简史：快速整合产生的断层》的系列之三，将继续着眼于大的工程方面的综合实践选型。 那么，有多少种oneforall？都有过哪些实现或案例呢？理想的oneforall呢,这样的终极方案始终存在吗？讨论它有意义么？ 虽然被不断怀疑，然而终极编程和“one for all”真的存在,它并不需要是类似编程葵花宝典之类的东西，我们可以理解让编程体现为适可而止，有止境的境界，在工程上(编程上让事情变得越来越容易最后不需投入或极少投入再学习成本)，通往其的方法可以有很多种，但一种无疑是那种—比如，某种直到脚本和可视编辑器级的工具级开发封装。如果编程方法可以归结为一门最终的哲学，学者可以利用它举一反三，完成自举学习，那么这种元性质的哲学，就是终极。图形界面的出现和DLL API机制，VB可视化，在这个意义上都是伟大的铺垫作品，面向对象也是一种终极编程，它在语言内在抽象接近平民，各种OO范式，PME，再后来，框架容器，都是使编程变得终极的方法和基础工作。 这些只是整合而已，严格来说其主旨只有二点：1）着眼于大的面向人的工程和实践方面，首先要保证这个一体化方案必须是方案全包和self contained的（没有断层，不用跨越，，不用四处找方案）。必须是“一元下的多元”。比如统一后端语言系统要包含多种前端做到no binding。就可视作是此。2）然后是平坦化（“多元下的一元化”）。能围绕一门语言良性地建立起实践的方方面面工程与选型，且所有其中的东西都是one style的no steeps，故这样的方案必须要包含一门语言，一种部署方案，然后使这一切形成平坦化的。可能最终归于一门语言系统级的封装实现中。 故最大整合，全包，又要求良性集成 – 尽量多用onestyle的抽象线索来整合并突出统一易用能用。才是其主要特点，而如上所讲，一元下的多元，多元下的一元onestyle其实并不矛盾 也许最好的例子，就是我们熟知的WEB和web开发界中.net这样的东西，WEB是一个涉及到运用云计算这些最新软件技术的领域，又运用了上述所有这些—-特别是语言上的开发技术，的地方如.net,js（当然还有更多…），是封装最完善最统一的领域，可以很好拿来作为例子。 《编程的最高境界是什么》：以web举例，onestyle WEB开发与调试设局的编程实践 WEB开发是现今最简单的开发，没有最简，因为它就是最简。 WEB前端开发门槛很低，因为在大量框架下，最前端的样式效果开发（实际上不叫开发，叫界面配置）已经变成纯粹的艺术行为了，因为它变成了debug and visual driven coding,或称programming,而js用来编程前端html dom 和style elements，也可用同样的调试和开发方式被调试。 而web app开发主要是处理一些服务性的api,云时代不同应用通过service api交互，服务性API，js+xml（json,etc..）让任何领域逻辑的开发编程，都变成都是界面编程下的逻辑(前端也是xml->html,css也有xml化的scss)。xml是数据化代码转领域逻辑的终极手段。 这二者是统一的技术一个可视一个XML语义化而已，使用相同的语言。这个层上的web开发就是一个充分经过了onestyle风格整合过程的多工程开发领域。这主要指问题域还有使用的语言，见下： 什么是终极编程及最好的实践语言，以js+.net举例 在前文《语言选型通史中》中我们谈到.net和JS，谈到前者的统一后端特性和后者的跨三界开发。 1) js为什么流行 a, 前端是一个对领域逻辑封装得最完善的领域，包括桌面GUI，HTML，网站模板技术，MVC范式等。html标识系统，JS作为前端语言内部的适用性，源于web前端，也能应用成为mobile,native的前端。 b, 而js也可用于后端服务器甚至传统native开发—当然这是非c runtime的而是jsruntime backend的（这属web的“系统编程”了，实现编程，区别前面谈到的service api应用），js+web有鲜明的one lang,one problemdomain solution的特点（这里js是nodejs实现或emcs规范，它被广泛用于服务端编程），虽然它只是在目前慢慢成为事实…。 你的第一门实践语言，应该是类JS的，松语法描述，调试资源丰富，从界面到逻辑，一条龙，可渐进，先前端再后端再全栈，是实践的最佳路径和起点。这或许就是为什么JS是越来越多地成为最佳实践语言的原因根本 2) 再来看.net和web的后端，系统编程和实现方面：面向多种定制化的平台，包括工具在内的全生态self contained 因为clr平台提供了最基础的后端和组件环境，包括语言服务，平台后端，工具在内的东西都可以定制成self contained的，可以说，统一后端，将原来native开发上可用的东西全弄到可托管后端支持下: a, 统一后端，也是统一了平台，跨mobile,web,native desktop,是第四代语言最鲜明的特征。 (与traditional c runtime backend nativedev分开,在这里，桌面开发分native上的桌面开发，和托管到.net clr上的桌面开发，.net上有自己的封装版本，所以这是另外一种全功能的跨desktop,web,mobile托管平台。不对native开发断层。) b, .net 可以直接调用语言服务，甚至新的语言完全可以通过dropin语言前端的方式放置的方式安装。因为在.net统一后端下服务即组件所以接入了后端的语言前端只是普通组件可按普通API方式调用。 c, .net这样的框架为IDE提供了一个统一。使得sharp,mono,vs这样的东西不致于存在像本地编译器那样的鸿沟，比如不必安装巨大的本地sdk，大家可以共用一套runtime（由于.net runtime即组件，组件即源码标准库，不必发布巨大的sdk），sharp,mono可以仅面向托管码，调试，智能提示可以轻易做得跟vs一样强大。 这点使得用户维护一个属于他们自己的，且跨三平台统一的codebase,runtime,ide,甚至一切成为可能并可打包带走。 它是一种根本上的迁移。只要是在迁移之上的东西，都是self contained.taken alway的。 架构已定，用户入阶和工具支持方面： 如果说选型已定（包括OS支持，语言，语言强化，服务端引擎，具体应用体系 — 这些往往被做在了一体化的语言或统一后端中，或PAAS环境中），那么这里就是尾端APP开发。由于问题域实在太复杂太多变太广泛，很难有大全的编程套件能兼顾覆盖全部领域，而.net这样的统一后端能容易裂变成子集又有社区包管理，能最大程度地向无架构APP开发靠拢。 充分的复用支持和应用域实现及工具级支持 —- 但这也是在当今时代，复用二字，是用户需要学会用他们解决问题的最基础方法和唯一手段，也是使用任何语言最基本的素养要求：.net开发只是设想你会任何一门它支持的语言，即使是vb.net或是某brainstorm。 1) engitor无架构APP开发： 全生态+无架构是微实践的基础。因为只有做到了无架构，才能避免在用户开发APP层级还进行复杂设计的必要，才能到达微实践的地步。架构和设计已在前面的语言整合中被解决了。 用户开发应该是二次开发，无架构，平坦式复用，，，而大部分时候我们都是在进行二次开发。以软件为体系进行该软件之下的扩展开发，形成的应用叫APP。那种带设计的大型开发，要么是重造轮子，要么是更复杂一点的二次开发而已。 比如，OO就是语法代码级的扩展。和二次开发。是语言级对开发是一层层堆栈或剥栈的事实反映，迭代是最安全的类OO之于demo继续演化的工程行为行为，也强调继承了以一点点叠加慢慢发展的思路。因为从抽象上说，软件本质就是栈的添加修正行为。所以，结合《编程实践养成过程反推式》：demo演化，也是编程。只不过它处在工程明显的地方，即尾端。 所以，用户设计中，应该尽可能地避免复杂设计和规模过大的问题封装。（导致的语言应用过于复杂和问题封装问题）那种为了特定问题提出一套语言特性的做法更是不可取。语言核心应该稳定，不应该从下而上地变，虽然从上而下地变是可以的。更不应该透给用户编程层。 2) 微实践： 在以上架构下，实践者仅要求有的基本素养，1你不需要懂太多，在你能控制的复杂度内干正确的事；2假设在新API面前，每个人都是脚本工具小子，这样就够；3,懂得适当的逻辑归类，甚至免OO，比如，你不习惯用OO，完全可以用编辑器或者用统一后端支持下的仅支持过程函数在源码文件中摆放编程的免OO DESIGN语言来编程。 一个能打包打包，在一个小时，一篇文章中讲完教完的编程实践才是好的自包含的微实践课程。这对最初级的学习者也适用。 .net和js，它们都是onestyle的code and demobase(说demo是因为有组件，这个demobase是comopentbase)，js npm社区有几行代码组成一个库的micro service存在。开发只是组合服务。 demo as engine+microservice开发兴起了，所以1dddemobase > 1ddcodebase了，找类qt的那种开发库组织1ddcodebase过时了。恩直接找大量第三方小件，杂乱的也行，只要搭出的demo具备好的facades就行了。 可复用件选型+小微开发，这一切得盖于最良性的基建结构—语言选型部分。 (此处不设回复，扫码到微信参与留言，或直接点击到原文)
2020年10月
-
10.27 22:35:00
发表了文章
2020-10-27 22:35:00
panel.sh：一个nginx+docker的云函和在线IDE面板,发明你自己的paas(1)
panel.sh：一个nginx+docker的云函和在线IDE面板,发明你自己的paas(1)
-
10.27 22:32:23发表了文章
2020-10-27 22:32:23
panel.sh：一个nginx+docker的云函和在线IDE面板,发明你自己的paas(2)
panel.sh：一个nginx+docker的云函和在线IDE面板,发明你自己的paas(2)
2020年09月
-
09.29 13:13:04发表了文章
2020-09-29 13:13:04
在云主机上安装vscodeonline
在云主机上安装vscodeonline
-
09.28 22:27:21发表了文章
2020-09-28 22:27:21
戒掉PC，免pc开发，cloud ide and debug设想
戒掉PC，免pc开发，cloud ide and debug设想
-
09.28 22:26:34发表了文章
2020-09-28 22:26:34
在openfaas面板上安装onemanager（2）
在openfaas面板上安装onemanager（2）
-
09.28 22:25:36发表了文章
2020-09-28 22:25:36
在openfaas面板上安装onemanager
在openfaas面板上安装onemanager
-
09.28 22:24:45发表了文章
2020-09-28 22:24:45
利用openfaas faasd在你的云主机上部署function serverless面板
利用openfaas faasd在你的云主机上部署function serverless面板
-
09.28 22:23:50发表了文章
2020-09-28 22:23:50
在pai面板上devops部署static site
在pai面板上devops部署static site
-
09.28 22:22:34发表了文章
2020-09-28 22:22:34
在云主机上手动安装腾讯PAI面板
在云主机上手动安装腾讯PAI面板
-
09.28 22:21:33发表了文章
2020-09-28 22:21:33
rcore,zcore,兼谈fuchsia:一种快速编程教学系统和rust编程语言快速学习项目
rcore,zcore,兼谈fuchsia:一种快速编程教学系统和rust编程语言快速学习项目
-
09.28 22:20:43发表了文章
2020-09-28 22:20:43
一种设想：为linux建立一个微内核,融合OS内核与语言runtime设想
一种设想：为linux建立一个微内核,融合OS内核与语言runtime设想
-
09.28 22:19:57发表了文章
2020-09-28 22:19:57
我为什么选择rust
我为什么选择rust
-
09.28 22:19:11发表了文章
2020-09-28 22:19:11
编程语言选型之技法融合，与领域融合的那些套路
编程语言选型之技法融合，与领域融合的那些套路
-
09.28 22:18:10发表了文章
2020-09-28 22:18:10
利用fodi给onemanager前后端分离(2):测试json
利用fodi给onemanager前后端分离(2):测试json
-
09.28 22:17:16发表了文章
2020-09-28 22:17:16
利用fodi给onemanager前后端分离(1)：将fodi py后端安装在腾讯免费cloudbase
利用fodi给onemanager前后端分离(1)：将fodi py后端安装在腾讯免费cloudbase
-
09.28 22:16:25发表了文章
2020-09-28 22:16:25
云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想
云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想
-
09.28 16:15:35发表了文章
2020-09-28 16:15:35
一种matecloudos的设想及一种单机复杂度的云mateapp及云开发设想
一种matecloudos的设想及一种单机复杂度的云mateapp及云开发设想
-
09.28 16:14:47发表了文章
2020-09-28 16:14:47
打造小程序版本公号和自托管的公号(3):为miniblog接入markdown和增强的一物一码
打造小程序版本公号和自托管的公号(3):为miniblog接入markdown和增强的一物一码
-
09.28 16:13:57发表了文章
2020-09-28 16:13:57
打造小程序版本公号和自托管的公号(2)：利用mini-blog将你的blog做到微信
打造小程序版本公号和自托管的公号(2)：利用mini-blog将你的blog做到微信
-
09.28 16:12:23发表了文章
2020-09-28 16:12:23
一键pebuilder，实现云主机在线装dsm61715284
一键pebuilder，实现云主机在线装dsm61715284
-
09.28 16:11:16发表了文章
2020-09-28 16:11:16
一个设想，在统一bios/uefi firmware，及内存中的firmware中为pebuilder.sh建立不死booter
一个设想，在统一bios/uefi firmware，及内存中的firmware中为pebuilder.sh建立不死booter
-
09.28 16:10:31发表了文章
2020-09-28 16:10:31
一键pebuilder，实现云主机在线装deepin20beta
一键pebuilder，实现云主机在线装deepin20beta
-
09.28 16:09:36发表了文章
2020-09-28 16:09:36
一种设想：在网盘里coding,debuging，运行linux rootfs作全面devops及一种基于分离服务为api的融合appstack新分布式开发设想
一种设想：在网盘里coding,debuging，运行linux rootfs作全面devops及一种基于分离服务为api的融合appstack新分布式开发设想
-
09.28 16:08:53发表了文章
2020-09-28 16:08:53
利用onedrive加packerpebuilder实现本地网络统一装机
利用onedrive加packerpebuilder实现本地网络统一装机
-
09.28 16:07:55发表了文章
2020-09-28 16:07:55
利用onemanager配合公有云做站和nas（2）:在tcb上装om并使它变身实用做站版
利用onemanager配合公有云做站和nas（2）:在tcb上装om并使它变身实用做站版
-
09.28 16:07:08发表了文章
2020-09-28 16:07:08
一个netdisk storage backend app webos和增强的全功能网站云设想
一个netdisk storage backend app webos和增强的全功能网站云设想
-
09.28 16:05:22发表了文章
2020-09-28 16:05:22
利用大容量网盘onedrive配合公有云做你的nas及做站
利用大容量网盘onedrive配合公有云做你的nas及做站
-
09.28 16:04:25发表了文章
2020-09-28 16:04:25
把DI当online packer用:利用installnet制作一个云装机packerpe（2）
把DI当online packer用:利用installnet制作一个云装机packerpe（2）
-
09.28 16:03:17发表了文章
2020-09-28 16:03:17
利用citrix xenapp and xendesktop建立你的云桌面
利用citrix xenapp and xendesktop建立你的云桌面
-
09.28 16:02:31发表了文章
2020-09-28 16:02:31
把DI当online packer用:利用installnet制作一个云装机packerpe（1）
把DI当online packer用:利用installnet制作一个云装机packerpe（1）
-
09.28 16:01:34发表了文章
2020-09-28 16:01:34
云主机装黑果实践(9)：继续处理云主机上黑果clover preboot问题
云主机装黑果实践(9)：继续处理云主机上黑果clover preboot问题
-
09.28 16:00:31发表了文章
2020-09-28 16:00:31
云主机装黑果实践（8）：利用clover，离我们的目标更接近了
云主机装黑果实践（8）：利用clover，离我们的目标更接近了
-
09.28 15:59:39发表了文章
2020-09-28 15:59:39
云主机装黑果实践（7）：继续处理云主机上黑果前后置问题，增加新boot
云主机装黑果实践（7）：继续处理云主机上黑果前后置问题，增加新boot
-
09.28 15:58:46发表了文章
2020-09-28 15:58:46
云主机装黑果实践（6）：处理云主机上变色龙启动后置过程：驱动和黑屏
云主机装黑果实践（6）：处理云主机上变色龙启动后置过程：驱动和黑屏
-
09.28 15:57:30发表了文章
2020-09-28 15:57:30
云主机装黑果实践（5）：重得到镜像和继续强化前置启动过程
云主机装黑果实践（5）：重得到镜像和继续强化前置启动过程
-
09.28 15:56:32发表了文章
2020-09-28 15:56:32
云主机装黑果实践（4）：阿里轻量机上变色龙bootloader启动问题
云主机装黑果实践（4）：阿里轻量机上变色龙bootloader启动问题
-
09.28 15:55:43发表了文章
2020-09-28 15:55:43
云主机装黑果实践（3）:得到云主机安装镜像
云主机装黑果实践（3）:得到云主机安装镜像
-
09.28 15:54:55发表了文章
2020-09-28 15:54:55
云主机装黑果实践（2）：在deepin kvm下测试mbr方式安装的黑果10.15最新版
云主机装黑果实践（2）：在deepin kvm下测试mbr方式安装的黑果10.15最新版
-
09.28 15:54:08发表了文章
2020-09-28 15:54:08
Linuxboot:linux as UEFI,linux over UEFI
Linuxboot:linux as UEFI,linux over UEFI
-
09.28 15:53:23发表了文章
2020-09-28 15:53:23
云主机装黑果实践（1）：deepin上qemu+kvm装黑果
云主机装黑果实践（1）：deepin上qemu+kvm装黑果
-
09.28 15:52:37发表了文章
2020-09-28 15:52:37
在阿里云上安装黑苹果的一种设想
在阿里云上安装黑苹果的一种设想
-
09.28 15:50:21发表了文章
2020-09-28 15:50:21
Dsm as deepin mate(3):离线编辑初始镜像，让skynas本地验证启动安装/升级
Dsm as deepin mate(3):离线编辑初始镜像，让skynas本地验证启动安装/升级
-
09.28 15:48:39发表了文章
2020-09-28 15:48:39
硬件融合的新起点：虚拟firmware，avatt的编译(2)
硬件融合的新起点：虚拟firmware，avatt的编译(2)
-
发表了文章
2020-10-27
panel.sh：一个nginx+docker的云函和在线IDE面板,发明你自己的paas(1)
-
发表了文章
2020-10-27
panel.sh：一个nginx+docker的云函和在线IDE面板,发明你自己的paas(2)
-
发表了文章
2020-09-29
在云主机上安装vscodeonline
-
发表了文章
2020-09-28
戒掉PC，免pc开发，cloud ide and debug设想
-
发表了文章
2020-09-28
在openfaas面板上安装onemanager（2）
-
发表了文章
2020-09-28
在openfaas面板上安装onemanager
-
发表了文章
2020-09-28
利用openfaas faasd在你的云主机上部署function serverless面板
-
发表了文章
2020-09-28
在pai面板上devops部署static site
-
发表了文章
2020-09-28
在云主机上手动安装腾讯PAI面板
-
发表了文章
2020-09-28
rcore,zcore,兼谈fuchsia:一种快速编程教学系统和rust编程语言快速学习项目
-
发表了文章
2020-09-28
一种设想：为linux建立一个微内核,融合OS内核与语言runtime设想
-
发表了文章
2020-09-28
我为什么选择rust
-
发表了文章
2020-09-28
编程语言选型之技法融合，与领域融合的那些套路
-
发表了文章
2020-09-28
利用fodi给onemanager前后端分离(2):测试json
-
发表了文章
2020-09-28
利用fodi给onemanager前后端分离(1)：将fodi py后端安装在腾讯免费cloudbase
-
发表了文章
2020-09-28
云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想
-
发表了文章
2020-09-28
一种matecloudos的设想及一种单机复杂度的云mateapp及云开发设想
-
发表了文章
2020-09-28
打造小程序版本公号和自托管的公号(3):为miniblog接入markdown和增强的一物一码
-
发表了文章
2020-09-28
打造小程序版本公号和自托管的公号(2)：利用mini-blog将你的blog做到微信
-
发表了文章
2020-09-28
一键pebuilder，实现云主机在线装dsm61715284
滑动查看更多
-
回答了问题
2018-05-20
独享云虚拟主机统统无法通过备案过程中的产品验证，提示备案主体超出1个
Re:独享云虚拟主机统统无法通过备案过程中的产品验证，提示备案主体超 ..是主机问题。
您提供的产品已经提交过网站备案，备案主体数已经达到了1个主体上限赞0 踩0 评论0 -
提交了问题
2018-05-20
独享虚拟主机可以由国内转到国外吗，控制台没对应选项，发工单可以么
-
提交了问题
2018-05-20
独享云虚拟主机统统无法通过备案过程中的产品验证，提示备案主体超出1个
-
回答了问题
2017-12-05
alicdn被墙
后台进得去，管理国内机器也可以刷出已有ecs实例
但是东京ECS，，刷不出来，也进不去网页vnc-------------------------
显示正在跳转东京区。。
一直卡在那-------------------------
引用第1楼dongshan8于2017-12-04 19:17发表的 :
版主回复：
能否发一个具体的文件URL地址，
让网友们为您测试一下？ [url=https://bbs.aliyun.com/job.php?action=topost&tid=571453&pid=1758690][/url]
你自己打开后台，进入东京区试试。-------------------------
这种效果
-------------------------
还有这种效果
赞0 踩0 评论0 -
提交了问题
2017-12-04
alicdn被墙
-
提交了问题
2017-07-18
日本节点为何快照不断计费
-
回答了问题
2017-07-15
日本节点间或性连不上远程，打开网页极慢
请阿里速排除原因，我不相信什么工单套路。也请懂的人出点主意-------------------------
就这几天的事。注意到日本节点由走上海换成改走北京了。。
阿云线路从运营上就不稳定啊多变动-------------------------
线路抽风
赞0 踩0 评论0 -
提交了问题
2017-07-15
日本节点间或性连不上远程，打开网页极慢
-
回答了问题
2017-06-30
阿里云做外贸网站，哪个ECS节点好
注意到香港B最近调线路了，现在不走美国
而日本从上海，现在绕到北京。。
5呼。赞0 踩0 评论0 -
回答了问题
2017-06-12
全民云计算会提供日本节点不
看到已追加越来越多节点了，
就把日本当宝似的赞0 踩0 评论0 -
回答了问题
2017-06-08
阿里云国外云服务器速度如何，有用过的没？
香港估计也不行赞0 踩0 评论0 -
回答了问题
2017-06-03
为什么我的ip可以ping通，但是从浏览器里就是打不开啊？
安全策略中把80打开-------------------------
在你ECS管理控制台中
赞0 踩0 评论0 -
回答了问题
2017-06-02
论坛里谁的网站是1核1G1M服务器的，想看看站点打开速度如何
ECS太依赖配置，记得把hosts中的localhost ip6禁掉。
这样mysql就和webserver直接通讯了。否则卡死你
有必要的话再配个redis。。
1M的也很快了。赞0 踩0 评论0 -
回答了问题
2017-06-02
ECS内存飙高
ecs来就是相当于上网本之于PC的区别。
它的CPU， IO,都是虚拟出来的。
性能不能类比。
CPU很容易飙升。控制程序出错是出路-------------------------
用windows啊。。。省事直观又方便，，最重要的，不会有你这种CPU窜升的问题，好像linux默认就是吃尽内存。
然后配wnmp赞0 踩0 评论0 -
提交了问题
2017-06-01
全民云计算会提供日本节点不
-
回答了问题
2017-06-01
建议独享虚机能买端口，，付费也可以啊。。
主要是不想维护ECS啊。想弄个足够简单，又刚好够用的赞0 踩0 评论0 -
回答了问题
2017-06-01
独享虚机麻烦弄个可选的windows2012 server操作系统
.net4.5都没有赞0 踩0 评论0 -
提交了问题
2017-05-20
独享虚机麻烦弄个可选的windows2012 server操作系统
-
提交了问题
2017-05-20
建议独享虚机能买端口，，付费也可以啊。。
-
回答了问题
2017-05-20
强烈建议独享主机开发个集成常见PHP扩展的选项啊。开放有限端口走socket啊
Re:强烈建议独享主机开发个集成常见PHP扩展的选项啊。开放有限端口走soc ..至少应该有一个swoole等的扩展吧，以显示独享与共享，在功能上的区别，，，
或其它增强扩展。。
这样才有卖点啊。。
否则不就是一个大点的共享虚机嘛。。赞0 踩0 评论0
滑动查看更多
暂无更多信息