git服务器 ssh协议

搭建的gogs 还有gitea, 新建的仓库都会有下面这个
git remote add origin [email protected]:sleepm/sample.git
但是push的时候又会有以报错
fatal: ‘sleepm/sample.git’ does not appear to be a git repository
fatal: Could not read from remote repository.
意思大概是请求的路径并不是一个代码仓库
好好想一想,冒号后面的是路径,因为用的root用户,所以,绝对路径是
/root/sleepm/sample
但git服务器配置的repository路径却是另外一个,比如
[repository]
ROOT = /root/gitea-repository/
仓库都在那个目录里….
所以,下面这样写就可以正常的push了
git remote add origin [email protected]:gitea-repositories/sleepm/sample.git

如果不想加那么长,可以在配置里把路径改成/root,然后重启gitea
再把原来的仓库移动到root下面,就好了

缺点就是….root下面会有很多目录,用户越多,目录越多…
挖个坑,git服务器的git协议
https://github.com/git/git/blob/master/Documentation/git-daemon.txt

javascript array的map forEach every filter reduce

map

var a = [1,3,6,4,5];
var new_array = a.map(function(value, index, array){
    console.log(value, index, array);
    return value;
})

跑一遍就知道了,上手敲,不要复制粘贴
map接收一个函数,然后新数组的每个元素是这个函数的返回值
这个函数接收三个参数,第一个是当前元素,第二个是当前元素的索引,第三个是当前数组;
这样子,看着好像没有实际用到的,举个例子

var links = [];
$('ul').map(function(value){
    links.push($(value).find('a').href);
})
console.log(links.join("\n"));

在某个资源站,下载电视剧,一个一个复制是不是很烦呐,将上面的代码改一改,控制台里走一走,链接全部出来了,就问你爽不爽😁

forEach
forEach的第一个参数也是个函数,也接收三个参数,这个参数和map一样,不过,它没有返回值,所以也就没有新数组产生
上面找资源链接的代码也可以用forEach去写,因为我们的目的是一致的,
都遍历数组,然后找到链接后加入数组,最后显示所有链接
第二个是可选参数,用作this, 在第一个函数里面可以用this,影响外部的对象,在某些时候还是很有用的,比如
不用再 var that = this;
然后在闭包里面用that了😂….

every
这个方法和上一个一样,参数列表一样,传的函数的参数也一样
不过,返回值是布尔,检验每个元素是否通过了传入的函数的测试,因为遍历了数组,所以我们还是可以用它整理资源😁

filter
这个方法也和上一个一样,检验每个元素,不过不同的是,通过测试的元素,会组成一个新的数组,返回值就是这个数组

reduce
这货也接收一个函数作为参数,官方举的例子很直接,就是从左到右应用那个函数,最后返回函数累计计算的结果
咱们能不能用它来处理电视剧资源链接呢😂,答案是可以的

$('ul').reduce(function(link, value, index, array){
    return link + "\n" + $(value).find('a').href;
})

嗯,如果 $(‘ul’)没有reduce方法,可以.toArray(),再调用reduce
发现了没,这个函数接收四个参数,第一个很特殊,它就是上次调用这个函数的返回值,
reduceRight 和上面那个哥们一样的,不过处理的顺序相反
//课外知识点 递归 迭代

循环数组的方法还有几个,sort,some,find,findIndex…待续

折腾nginx + varnish + apache2 https整站小记

原来的配置是varnish + apache2, varnish直接监听80, http传给88的apache2,或者击中缓存,  https不走缓存直接给apache2. http+https很不爽…所以折腾整站https

现在

nginx:80,443

varnish:8888

apache2:8080

下面贴配置

server {
    listen 80;
    server_tokens off; #隐藏响应头中的nginx版本

    root /var/www/www/blog/public_html;

    index index.php index.html index.htm index.nginx-debian.html;

    server_name xn--vkuk.org;

    return 301 https://xn--vkuk.org$request_uri; #强制http请求跳转到https
}

server {
    server_tokens off;
    server_name xn--vkuk.org;
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/xn--vkuk.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/xn--vkuk.org/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


    location / {
        proxy_pass http://127.0.0.1:8888; #varnish监听的地址
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Scheme $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}
backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

backend blog {
    .host = "127.0.0.1";
    .port = "8081";
}

sub vcl_recv {
    if(req.http.host ~ "osteam.win"){
       set req.http.host = "osteam.win";
       set req.backend_hint = default;
    }
    if(req.http.host ~ "xn--vkuk.org"){
       set req.http.host = "xn--vkuk.org";
       set req.backend_hint = blog;
    }

    //set req.http.X-Forwarded-For = client.ip; //把nginx获取的用户ip传给后端
    //https://stackoverflow.com/questions/25558749/varnish-automagically-adding-load-balancer-ip-to-x-forwarded-for-header apache2能读取到ip了,但是后端程序还是还是需要调试下...挖个坑待填
}
#你以为这样两个站点就分开了么? 实际测试重启varnish服务后, 先访问哪个站点,哪个被缓存,再换域名访问,看到的是刚缓存的那个主页... 很崩溃
sub vcl_hash {
  hash_data(req.url); #先校验url
  if(req.http.host){ #如果有host头,就校验host
    hash_data(req.http.host);
  }
  return (lookup);
}
#当然,这个只是部分配置
#原来的配置是参考
#https://leonax.net/p/8243/staticalize-wordpress-via-varnish/
#注意,不同的varnish版本, vcl的语法不同...

接下来,就是apache2了… 这个有坑…原先的配置有监听443,然而忘记了.. 搞得nginx半天起不来…

ServerName 191.101.152.69 #如果启动apache2服务有报apache2不知道servername, 可以设置这个, ip是你的ip, localhost应该也可以
#再001-blog中修改并不会监听8081, ss -l 也没有8081 curl localhost:8081 -v 也是拒绝访问,必须在下面加
NameVirtualHost 127.0.0.1:8080
NameVirtualHost 127.0.0.1:8081
Listen 127.0.0.1:8080
Listen 127.0.0.1:8081
#
#    Listen 443
#
#有关443的全部注释

apache2的站点配置只需要把原来的443的全部删掉就行了
varnish 4.1
apache2 2.2.22
nginx 随意…配置文件语法好像没怎么变过, 还有就是为了安全…万一哪天我这个版本被曝漏洞,凑巧我还没打补丁,再凑巧因为这个被肉鸡了可不好?

嗯, wordpress 最好提前装上个

SSL 不安全内容修复器


因为,改了siteurl homeurl 好像并没有起作用, 主题里的静态文件依然是http, 原来http+https的时候, https好好的… 不知道什么鬼
以为是nginx没有正确的把请求头传给后端, 一顿折腾,有了上面那个配置,依然不行…装上这个, 再好好设置, 然后重启varnish服务,好了…
不知道遇到什么鬼,就重启varnish…缓存太强了….
附一个varnish 4.1 的中文文档
https://jefferywang.gitbooks.io/varnish_4_1_doc_zh/

wake on lan 远程唤醒

有这么种数据包叫魔法数据包。
这个魔法数据包中包含:有线网卡的MAC地址,SecureOn密码。
计算机关机之后,网卡还会有轻微电流继续工作。
接收到这个包的网卡会检查这个包里的内容,如果MAC地址与自己的一致,就唤醒计算机。
这个需要bios里启用wake on lan,不过没见到过。。。可能是旧版本的bios有这个设置。。也没见到过网卡不支持的情况。。在设备管理器找到网卡,属性里可以找到wake on lan
如果要发送魔法数据包,你需要一些软件去帮助你实现。维基百科下面列出来一些。
https://zh.wikipedia.org/wiki/WOL
需要指定目标ip,如果内网唤醒,那就有点没折腾的意思了。。内网也是可以的,如其名就是为内网准备的。。
不过公网也是可以的,如果目标主机在内网中,需要在路由器中设置虚拟服务器,端口设置为7或9,ip为内网ip,这样发送到路由器的魔法数据包就会转发给目标主机。
获取公网ip,可以使用动态dns服务,只要路由器登录了动态dns,那么ip就填写动态dns给的域名就行。
我参照下面这个脚本写了个页面。。https://osteam.win/wol.php?ip=1.1.1.1&mac=11:11:11:11:11:11
https://github.com/PHPGangsta/WakeOnLAN
不过,还是不要把ip和mac随便透漏给别人,万一有人闲的唤醒你电脑,多不好?

laravel 任务队列

官方文档写得挺好的,不过还是写下自己的理解,省得翻老代码还骂这啥代码,谁写的?

./artisan queue:table
#生成任务队列数据表的迁移文件
./artisan migrate
#执行迁移
./artisan make:job fetch_page
#新建一个抓取页面的任务,名字随意,只要便于理解就行

先不管这个文件长啥样,大概了解下原理
laravel 使用 ./artisan queue:work 来作为守护进程执行分发的任务
因为这条命令是由php来执行的,所以在php.ini中有最大执行时间,到了这个时间,不管执行的如何,它都会挂掉
即使最大执行时间足够大,但也可能因为一些不可控因素挂掉。。。
所以要配置supervisor来让它挂掉后重新起来。
把分发任务放到控制器中,然后写路由,然后编辑crontab
如果是web路由,就定期访问访问那个页面分发任务
如果是console路由,就定期执行那个命令
如果由用户控制,或基于事件,比如下面这个,用户提交链接,然后把任务加入队列
现在来写控制器

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

use App\Helper\Page;
use App\Jobs\fetch_page;

class PageController extends Controller
{
    /**
     * 分发页面任务
     * 队列就是先进现出FIFO,所以可以按次序将任务压入队列,它们将按顺序执行
     * @return void
     */
    protected function cron($url)
    {
        //抓取页面 注入依赖以及参数
        dispatch(new fetch_page(new Page, $url));
    }
}

来设想一个场景,用户提交一个待抓取页面,然后用户就可以去忙别的,或者继续提交。否则,用户只能等上面这个流程走完之后才能提交下一个。这是多么浪费生命的事情?
再来看看这个任务文件

worker = $worker;
        $this->url = $url;
    }

    /**
     * Execute the job.
     *
     * @return void
     */
    public function handle()
    {
        $this-worker->fetch_page($this->url);
    }
}

supervisor的配置安装如果有问题,就去看官方的readthedoc文档,看文档去填坑吧。。