jpuyy的网志

Blog

  • cloudstack kvm

    Creating a Qcow2 virtual machine

     

    xenserver vhd格式模板制作
    1.虚拟机用cobbler装系统，cobbler中设置磁盘类型为xvda，安装xenserver tools，http://support.citrix.com/proddocs/topic/xencenter-61/xs-xc-vms-installtools.html
    2.将虚拟机设置成模板，导出，一般为xva模式
    3.在xenserver中添加一个SR，即8.34的192.168.8.34:/templates
    4.导入之前导出xva模板，导入的位置为nfs，导入完成后，在everything中可以得到一个http的链接，格式为vhd。
    5.在cloudstack中添加xenserver模板，系统选择Other PV(64bit)。
    kvm qcow2格式模板制作
    1.找到一台qemu-kvm的宿主机，创建一个qcow2磁盘

    qemu-img create -f qcow2 -o preallocation=metadata /data/kvm003.qcow2 20G

    2.创建一个到cobbler的桥cloudbr1

    3.使用cobbler安装系统

    virt-install –connect=qemu:///system –network=bridge:cloudbr1 –initrd-inject=/data/201HD-kvm-test –extra-args=”ks=file:/201HD-kvm-test console=tty0 console=ttyS0,115200″ –name=kvm003 –disk path=/data/kvm003.qcow2 –ram 2048 –vcpus=2 –check-cpu –hvm –location=http://192.168.0.42/cblr/ks_mirror/CentOS-6.5-x86_64/

    4.装好系统后，检查网卡设置，将mac等信息去掉，测试虚拟机切换回8段的桥后是否正常.关机

    5.用file可以查看kvm003.qcow2是raw格式，转换为qcow2格式，

    qemu-img convert -c -O qcow2 kvm003.qcow2 convert.kvm003.qcow2

    检测是否有问题

    qemu-img check convert.kvm003.qcow2

    6.挂载nfs，上传到192.168.8.34:/templates

    7.在cloudstack中添加kvm的模板

  • 李嘉诚

    12岁就开始做学徒，还不到15岁就挑起了一家人的生活担子，再没有受到过正规的教育。
    当时自己非常清楚，只有我努力工作和求取知识，才是我唯一出路。
    我有一点钱我都去买书，记在脑子里才去换另外一本。
    但到我今天来讲，每一个晚上在我睡觉之前，我还是一定的看书。
    知识并不决定你一生有财富增加，但是你的机会就更加多了。
    你创造机会才是最好的途径。
    李嘉诚如此放弃香港的优良资产套现，不由得想起他曾说过的一段“商业圣经”：一个新产业，当5%的人知道时你赶快做，做早了就是先机；当50%的人知道时，你做个消费者就行了；当超过50%的人都知道时，你连看都不要看了。这是亚洲首富的经验之谈。素有“超人”之称的他，数十年商海遨游鲜有败绩，显然，李嘉诚意识到房产的风险正步步逼近，提前抛售套现，占尽先机风流。i

  • 正常情况下TCP/IP协议中SYN握手大致上如此：

    正常情况下TCP/IP协议中SYN握手大致上如此：

    1. A（发起者）发送一个SYN给B（接收者）
    2. B回复SYN-ACK给A
    3. A回复ACK给B
    4. 连接成功！

    这个过程的缺陷是，如果A是有恶意的来源，始终不停的发送SYN给B，那么B就会不停的建立起空连接（未完成的连接）等待A的ACK响应，只要A不回应，B的空连接就会不断的消耗资源，直至无法响应。

    这个缺陷事实上不是操作系统级别、防火墙级别的缺陷，而是来自于TCP/IP协议本身的设计缺陷。

    看了一下NetScreen的Screen安全策略中有针对它设计的SYN COOKIE设置。

    个人理解下来这是一个很讨巧的方法，但是略显笨拙：

    1. NS之外的A发送了一个SYN请求给内网的B
    2. NS截获了这个请求，没有直接将数据包转发给B，而是自己生成了一个假冒的SYN_ACK包回复给A
    3. A回复了ACK，成功完成握手
    4. NS将之前的SYN请求发送给B
    5. B发送SYN-ACK
    6. NS回复ACK
    7. NS搭建A到B的正式通道

    这种方式类似于中间人的方式实现连接，一定程度上是可以保护B不受攻击的侵扰。但事实上如果这时的A有足够的资源，完全可以让NetScreen建立的空连接达到无法响应的程度，这样实现的效果反而远远大于直接对B发起的攻击。

    对于类似的方法，Netscreen没有响应的设置，相应的文档上也没有给出解释。个人认为，NS应该是有一种判断机制，比如说时间或者频率。正常情况下是允许ACK回复延时的，但延时到了一定程度，或者这个来源不停的建立这种通信达到一个阀值，NS将会启动处理机制将A拉黑，同时关闭所有与A有关的连接。

    总的来说，SYN-ACK-ACK攻击属于不对等攻击，与DDOS，泪滴等攻击一样，发起攻击的成本要远远低于预防攻击的成本，这是TCP/IP的缺陷，只要不放弃TCP/IP，这样的攻击就会一直存在。而且防止前提必须是“已经受到了攻击”之后，即只能医治，无法预防。

  • 程序员用计算机语言写代码，就像 作家用文字写书

    程序员用计算机语言写代码，就像
    作家用文字写书

    不在于你用什么语言写，而在于你有能写名著的才能。
    语言，只是个把你的才能表达出来的工具。

    虽然工具有时候很重要，但更多的时候，还是你的才能，决定了你能输出什么：
    程序员：是垃圾代码还是高质量代码；
    作家：是错误连篇的帖子，还是世界级名著。

    生活和工作中困难是有的，我克服困难的方法有两个核心点”不断尝试”,”坚持”。
    是什么支持我走下来?如果我说是小时候的理想，这可能就真太荒谬了，
    真正支持我走下来的有两点，第一，我喜欢这个职业。第二，生活需要,DBA的收入不高，但是生活还是过得去。

  • Nginx的一些问题的解决办法集

    Nginx的一些问题的解决办法集
    Nginx的”413 request entiry too large”解决办法 由于默认是文件上传大小限制 1M。 今天一版主找我，说在上传的时候出现，
    引用:
    413 Request Entity Too Large
    问我是不是论坛抽了，我晕，检查发现就算更改php.ini 允许上传文件大小是8M，但是在使用过程中，大于1M的文件根本上传不了，找到解决办法，下面跟大家分享： PHP的上传设置： post_max_size = 8M upload_max_filesize = 2M  #vi /etc/nginx/nginx.conf 找到http{}段，加入如下一句： client_max_body_size 8m; 注意，最后的那个；号一定要有。

  • 港剧经典语句

    发生这种事，大家都不想的。 感情的事呢，是不能强求的。 所谓吉人自有天相， 做人最要紧的就是开心 。
    饿不饿，我给你煮碗面。