基于Flask的简易webtelnet和webssh

2020-02-25 作者:

Chinese version README of the Github repo – flask-remote-terminal.

简而言之,一台具备多用户支持的,仅限使用telnet/ssh,访问远程固定地址的,web终端。

演示截图:


有啥稀罕的

  • 只可访问远程地址,非本机终端
  • 目前仅限telnet(支持十几年前老设备用)和ssh访问,代码中也可增加其他协议,但始终受控
  • 仅限访问固定远端地址(IP/域名),代码config可配,一旦服务运行后不可更改
  • 服务端session存储pid和fd等,用于多用户支持


参考项目


需求如此“扭曲”,何解

通过web终端去管理一台特定的中转机,其多数端口是(在特定时间段内)代理到真正需要管理的目标机。具体需求如下:

  • 同多数web terminal一样,浏览器即开即用,免安装
  • 只允许访问特定地址(中转机),避免被抓肉鸡
  • 只允许使用telnet和ssh进行连接,不可自选其他客户端命令,在此基础上允许用户自行输入用户名和端口号
  • 只用于远程连接,在用户exit退出终端后,也无法回到shell操作提供该服务的server
完整阅读本篇»

OpenWRT配置FRPC实现公网访问

2020-02-23 作者:

This post talks about running frpc (Github), the client of my favorite reverse proxy toolset, on an OpenWrt powered router, to expose one or more specific port of an local/intranet ip address onto public access.

在目前主流网络运营商大多不提供公网IP的大环境下,FRP套装搭配一台低配云主机,是最普遍也相对稳定的ddns替代方案。

长期以来,笔者使用的都是x64(amd64 on Centos/Ubuntu)和arm(树莓派)版本的frp release,启动配置上都是走的linux systemd。今天算另辟蹊径,要介绍一下在一台EX6200v2刷机的OpenWRT上跑frpc,接通阿里云的frps,来实现公网访问内网。其中frps也即服务端的配置,网上海量教程,张大妈上每个博主都截图讲一遍,本文不再赘述。

 

在openwrt上运行frpc,要用到的资源来自于这两个Github工程,openwrt-frpluci-app-frpc

第一步,先搞清路由器的CPU架构。

本文用到的是NETGEAR EX6200v2,经查板载高通IPQ4018,4核Cortex A7 Neon。如果是用Intel处理器的软路由,那就更好办,直接省去查cpu的这一步。

当然,从ssh登进路由器确认,也是一种办法。

第二步,查看路由器的存储空间是否够安装FRPC,然后去github release下载相应的ipk安装包。

从返回结果看,可用空间还有7.3M,frpc安装包尺寸3.6M,还是可以安装。前提是ipk要放在临时分区也就是/tmp(猜测这货是内存虚拟硬盘吧)中。

完整阅读本篇»

记FSX第一次放单飞

2019-10-20 作者:

Since MS has announced its Flight Simulator 2020, I finally start my self learning on FS-X. With a newly purchased Thrustmaster T16000M FCS + TWCS throttle joystick set, the experience of flight simulation (on Cessna 172) turns to be complete fun, with some challenge, still. After all the torture by “mouse yoke” will never be a nightmare then.

And the famous flight instructor, Rod Machado, really helps me quite a lot with his professional and full-of-humor instructions in the Learning Center of FSX. I wrote down pretty much notes and charts on my evernote, which was exciting, pretty much.

经过大概一周“地面学校”自学,和不超过8个小时的空中单项训练,哥们算是把模拟器“首次单飞”(First Solo)给过了,还领了签了名的T恤残片,不得不说,仪式感满满(哪怕是在模拟器中)。

单飞的过程,简单来说,就是做完整一个本场五边。

  • 华盛顿州,布雷默顿机场,跑道编号19,指向190°(南偏西)。
  • 离场边。全油门起飞,爬升速度稳定在80 knots,对塞斯纳172而言,pitch角度控制在10~15度之间基本就可以。
  • 到1500英尺后,收油到2200 rpm(转/分),调整trim平飞。
  • 即刻收到教练指令,左转90°,完成后航向100°,高度保持。进入侧风边。
  • 平飞后,迅速再左转90°,完成后航向10°,高度保持;下风边,与起飞反方向,左侧舷窗可以逐渐看到跑道。
  • 位置大致平行于跑道始端时,受命展开襟翼至10°,下压姿态并适当trim,让飞机降到1300英尺。
  • 立即左转90°,完成后航向280°,继续以1300英尺高度平飞(此时奔着一座小山飞去,还不让拉高…),这是基线边。
  • 迟疑片刻,受命做最后一个90°左转,完成后航向回归到190°,这就是最终进近边,或者叫进场边。
  • 减速,对正起飞时的19号跑道。此时教练提示,利用第六课学习的PAPI(精密进近航道指示器)调整自己的glide path,接地前做好flare(改平),接地,刹车停稳。
  • 剪T恤签名发证收工,一气呵成!

 

第一件,先把student pilot的单飞证给亮出来。

再来个现实中机场的环境,GMAPS上显示跑道号是20,模拟器中是19。

话说模拟器中居然连现实环境中的旁边的赛车道都给做进去了,真的是很用心,别忘记模拟器发布是在10年前……

接下来是考试内容,注意底下的FLIGHT CRITERIA;只要有一项不符,且教练提示后没在规定时间内纠正的,直接判考试失败:

  • 高度在要求的100英尺内。
  • 动力系统在要求转速的上下100转内。
  • 飞行期间空速在要求范围的上下10 knots内,起飞期间按55 knots上10下5来界定。
  • 航向偏差在10°以内。
  • 俯仰偏差在3°以内。
  • 滚转时按10°进行(此处怀疑有typo,以往练习一般要求20°,而且句末有as assigned)。

以下过程截图 – 起飞爬升期间

btw 一直第一人称飞的,要真学就得靠仪表,不能当成游戏玩;截图么,还是第三人称好看咯

完整阅读本篇»

EX6200v2刷写OpenWRT秒变路由

2019-06-27 作者:

OpenWRT (LEDE) 18.06 turns the NETGEAR EX6200v2 from a WiFi extender to be a professional router with 1 WAN and 4 LAN ports.

首先,不得不说,我收到的这台EX6200v2整机可靠性相当一般。几个月以来一直相对稳定的AP无线信号,近期则是一天到断上1~2次,硬件现象是所有LED不停闪烁,要恢复WiFi需要拔电重启——对于多人办公环境而言,这是无法接受的;不仅如此,重启后还丢配置也是醉了。

想来难道是气温问题?前阵子一直表现稳定,近期随着夏季来临,办公室面西隔间逐步达到30+度,EX6200v2的电源渗出气味诡异的黄色油液,在我闻起来蛮像烟油的味道,太太则说像是电解液渗漏的气味。刷机后,要换个12V供电电源测试几天再看效果。

其次,言归正传,感谢为EX6200v2编译固件的玩家tonynee,其原贴从此访问

迄今为止,EX6200v2应该还没有获得openwrt官方支持,相比之下,其前辈EX6200(也即V1?)是有ddwrt支持的,因此讨论V1的中英文资料都不少,而V2却只有tonynee的自编固件可以完美下载刷入。别看只是V1、V2之分,据称V1是博通(Broadcom)方案,而V2则是高通(Qualcomm)方案,硬件上(包括编译时所用驱动)看来是没有多少相关性了。

诚然,刷固件和硬件可靠性并无直接联系,但即使宕机也得有个缘由吧?原厂固件一没个像样的日志,二连个CPU温度都看不到,明知有问题又无法诊断,只有UI好看又有何用呢?

于是,秉承“能动手就别BB”的态度,咱跟着tonynee沾个光。【友提】刷机有风险,操作须谨慎。

固件搬运(作者tonynee)

刷写过程简单到难以置信,不用降级原厂固件(版本1.0.1.74),也不用拆机找UART口接线。下载固件解压后,直接在原厂固件的“升级固件”页面,选择img文件,点升级等重启即可。

完整阅读本篇»

论VT-d对虚拟化NAS之价值

2019-03-02 作者:

Here the post is to talk about how to build a vm-based homelab NAS file server to make the entire unit (host and vm guest) working perfectly well, with both low power consumption, and highly flexible features like timer power on/off, completely spin down HDDs (as data warehouse) with a “power-off” vm – while the host is running well in 7×24. And the key to all of those, is Intel VT-d (feature of x64 processor), with an extra SATA controller attached on the motherboard.

Then btw, clear thinking, after 10 years working experience, should be considered as one of the most valued personalities of a professional.

硬件:产自圣地华强北,3205U,4 Intel i211,HDMI,4 USB,3.5mm音频,1 9pin COM

初始状态:一台基于KVM虚拟化的NAS(文件服务器),Host系统是Proxmox VE 5.3。

  • 当大部分教程选择esxi 5.x时,博主经仔细选择玩了PVE,原因1母鸡是标准debian本身可以做很多事(比如crontab,比如nfs server,比如gitlab等),2基于kvm稳定且不缺文档,3开源,4玩转了可以在工作中使用,毕竟是远近驰名的专业私有云solution。
  • 小鸡操作系统是DSM6,参考别的资料,应该是基于BSD的定制魔改版本。
  • 虚拟机(小鸡)分配2核1.5G内存作为计算资源。
  • 硬盘共3块。
    • sata1,引导盘,尺寸50M,用于引导无系统的DSM6进入可以安装系统的状态。虚拟盘,位于母鸡Intel SATA控制器下的mSATA SSD上的一个qcow2文件。
    • sata0,系统盘,尺寸20G,用于安装DSM6系统。同样虚拟盘,位于母鸡Intel SATA控制器下的mSATA SSD上的一个qcow2文件。
    • sata2,数据盘,尺寸2.0T,从基于PVE(Proxmox VE)的母鸡“伪·直通”到小鸡的物理磁盘。
  • 网卡是从PVE母鸡“真·直通”到小鸡的物理网卡,Intel i211千兆网。

 

存在问题:一台既无性能,也不可靠的文件服务器。

  • 所谓无性能,就得搞明白“真·直通”和“伪·直通”的区别,这里有关于Intel VT-x和VT-d的简介
    • 对于已经通过VT-d做了直通的i211网卡,其DMA和Interrupt都会remapping到虚拟机去,不再累及母鸡的cpu和内存来做传声筒;换句话说,几乎等价把母鸡的物理外设直连到了小鸡。小鸡关机,可以直接关掉物理网卡,这一点是最好佐证。
    • 而对于通过PVE命令“qm set –sata2”接到小鸡的磁盘,无非是把母鸡身上这个整体存储区间(整个硬盘),映射到小鸡虚拟的sata2通道(看起来还是整个硬盘)。也就是说,所有从小鸡对这块磁盘的读写,事无巨细都得母鸡全部过一遍,中断响应和IO性能差异高下立现。
  • 所谓不可靠,此处指两点细节问题。
    • 首先,对“伪·直通”的硬盘。我们到小鸡身体里面看(下图右),虚拟出来的QEMU SATA硬盘,其身份信息以及可支持的健康功能统统不见;与同一块硬盘在母鸡身上所得的详细数据相比(下图左),堪称凄惨。这就造成DSM6系统对磁盘健康程度(SMART)是一无所知的。
    • 然后,单数据盘,无RAID,对文件服务器而言……尤其对于一台连磁盘的SMART状态都看不到的服务器,屋漏偏逢连夜雨,绝了。

 

解决思路:把SATA控制器“真·直通”到小鸡。

  • ↑这是tm不可行的,常见家用计算机,包括我手里这台软路由,只有一个SATA控制器。意即给母鸡的系统盘,和给小鸡的数据盘,挂在同一个SATA控制器下,一根绳上蚂蚱,要走都走,要留都留。
  • 既然如此,那么外接一个SATA控制器。接在哪,去看技术手册。

完整阅读本篇»

基于阿里云API实现简单DDNS

2019-02-28 作者:

This is a post talking about using Aliyun Domain Control API (and python sdk as well) to script a simple, self-own ddns service, with only one assumption – a public ip over WAN port of your router.

 

原始状态

光猫 <—> R7000主路由 <—> 需要出门的母鸡+小鸡们

 

设计思路

  • 办法1:破解光猫,将光猫与R7000桥接。
    • 优势:内网只有一层,简洁明了。
    • 劣势:打N通电话,下N多工具,还要将独立IPTV信道映射或proxy到R7000的某个LAN口。
  • 办法2:硬件不做任何变动,添加两层映射。
    • 优势:实施安全性高。
    • 劣势:理论上,走ddns经双层转发,传输性能受影响。
  • 总结:人老色衰,首选安全方案。

 

网络拓扑

【更新】代码已推至github,欢迎加星。

完整阅读本篇»