shmilee
shmilee
本想发个issue的，结果发现本仓库只是专注于标准化菜谱。那我关于TIPS的建议还是贴这里吧，一些和标准有些联系、可能很难实现的想法。 > 建议把TIPS构建为一个标准库，并配有详细的说明文档 > ------------------------------------------------------------ > > 偶然逛到这里，看了一些菜谱，首先是饿了，其次是感觉菜谱只有点形式上的程序化，tips又相对很简略，看完总觉得缺点什么。 > 所以我想，如何在清晰描述网上菜谱的基础上更进一步，能不能在烹饪方法的基础上从更底层的逻辑描述HowToCook？ > 比如那么多红烧XX，是不是有冗余呢？不管是茄子还是肉类，红烧总有通用的材料和操作吧。 > 考虑到每个人有每个人的偏好，原材料的缺失，时间的限制等，菜谱要有一定的Robustness吗？ > 菜谱模板里有必备原料，那可替换原料，可选原料，建议原料呢？还有异常处理，默认参数等。 > 再就是有些菜谱、概念有争议，如#907，#858，大部分菜谱可以有弹性，但有共识、有标准的还是要专业一些。 > > 但以上其实不是最重要的。我觉得最好菜谱可以少一点，只选经典的，争议少的，其他的菜谱可以另开个仓库，放到数据集里。 > 与此同时将TIPS作为项目重点，做成标准库，配上文档，讲清楚**参考来源**、**注意事项**、操作**目的**、为何可行等等，感觉这些的标准化，比某道菜里放了几克盐更有意义，毕竟烹饪方法、经验、技巧比菜谱更有用。然后每一个菜谱就相当于复习标准库中几个方法的调用，不断的巩固加强。这样可能会更容易实现**面向对象**写菜谱吧。 > 菜谱少一点维护上也轻松点，同时既然是经典菜，已改会有一定的发展创新史，更新历史、版本号也少不了。 > 还有单元测试、 benchmark等，可以根据TIPS的*参考来源*制定。不过，编写tips可能会提高pr的门槛，打击大家的积极性，同时示例菜的模板也需要大改，还是需要做一定的取舍的。 > >...
docker里的模拟器？这个 https://hub.docker.com/r/redroid/redroid 不知有没有用？好像可以安装apk 最终是在PC里打包arm的软件，放到板子上运行吧？ 可以参考这个 https://docs.docker.com/buildx/working-with-buildx/ 题外话：有没有想过多个版本同时运行的方案？ 比如镜像里去掉安装包里的/usr/share/sangfor/EasyConnect，运行时按需要的版本挂载。镜像内只保留依赖和自定义脚本，多版本共用，可以省点体积。 conf也需要分多个目录对应不同版本。注意端口映射冲突。（我先试试，正好可以根据自己需要，开个ssh换掉dante）
Can you give me the download url of package 7.6.8 provided by your organization? Maybe I can write some codes to support it in my repository. All I need is...
> @shmilee I don't have link for 7.6.8, I said it's not provided by my org but from your cli image. Forget the version number 7.6.8 or something else, I...
``` [2021-03-30 07:37:46][I][ 368][ImportCertCommon]ImportCertCommon, Failed to Base64Decode for filePath: /root/xxxxx.p12. ``` ``` [2021-03-30 11:16:42][D][1295][SelectCertByIssuer]xxxxx.p12 is not cert, skip it ``` 我感觉是证书本身有问题,。了解了一下 P12/pfx pem/key的区别和转换，猜想可能的情况是： 1. p12是二进制文件，而pem/key crt这些都是base64加密的文本 2. `easyconn login`需要的应该是pem/key crt，无法处理p12的复杂格式...
@wushuzh > 使用 openssl 从 p12 文件中，分离出私钥文件，在容器交互提示中输入该文本文件挂载到容器中的完整路径，日志中仍然显示 ImportCertCommon, Failed to Base64Decode for filePath: xxxx (p12 full path name within container) 分离出两个文件吧？证书还有密码的话，三个参数 `-c -m -l`应该都需要。具体怎么对应输入的，你可以测试记录一下给大家看一下吗？
看到有好几组 Request，Response，包含了一些敏感信息，有本地的cert，key，也有server的cert，感觉足够从里面分析出认证的过程。 如果服务器那边也不识别p12文件，那假设GUI必须走命令行一样的认证流程，毕竟他们都是通过ECAgent认证。 那如果对比一下GUI客户端成功的日志和命令行失败的日志是不是更容易发现问题？ Update-1: ECAgent可能支持p12，上面的估计没用。 ``` strings ECAgent|grep 'pk12 cert' :( 1 [%4d][%s][CertUtil] pk12 cert:%s file does not exist! subjectName(%s) serialNumber(%s) errno:%d(%s) [%4d][%s][CertUtil] pk12 cert:%s can't access! subjectName(%s) serialNumber(%s)...
如果手动改url能成功显示图片，并最终跳转到搜索结果页面。 可以通过修改nginx的配置来自动解决： ``` server { listen 443 ssl http2; server_name google.shmilee.io; ................省略.................... location / { google on; google_scholar on; } .................以下是重点.......................... location ~ ^/ipv4/sorry/ { google on; subs_filter '(
同遇到，  试着解决了几步： - 到 https://www.google.com/recaptcha/admin 加入自己的 Domain， 获得一枚 Site key，复制备用。 - 修改 配置文件，默认sitekey(6LfFDwUTAAAAAIyC8IeC3aGLqVpvrB6ZpkfmAibj)从网页中获取。 ``` location / { google on; google_scholar on; subs_filter '"sitekey":"默认的sitekey"' '"sitekey":"第1步得到的sitekey"' ir; } ``` - 验证，点图片，完成后是这样的...
弃用了，现在fq，直接访问google学术