Ubuntu安装MySQL无法设置密码的处理一例

2015-01-09 • 技术文章

同学买了个VPS,自己装不上MySQL,遂请我帮忙。

简单地使用apt-get install来安装,在设置密码时终端返回信息fopen: Permission denied,很显然是权限问题。查看/var/log/mysql/error.log,发现ERROR: 1005 Can't create table 'tmp_db' (errno: 13)这个错误,具体定位到/usr/sbin/mysqld: Can't create/write to file '/tmp/iblrF3x1' (Errcode: 13)。也就是说,可以确定mysqld的进程无法对/tmp目录进行读写,再进一步说就是mysql用户无法对/tmp进行读写,遂授予权限。

再重新安装,安装没有再提示无法设置密码,但是在终端用root登录时提示ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES),使用/etc/mysql/debian.cnf中提供的用户名和密码进行登录,查看mysql数据库的user表,发现根本没有root这个用户。这时我们或许可以insert一个root进去,但是这样是否会带来其它的问题不得而知。怀疑是起初设置密码失败遗留的原有data目录下的数据库造成的,遂彻底删除mysql所有的数据和配置再重新安装。重新安装后,root终于出现了,设置密码也可以登录了。

由于这个VPS的是暴露在公网上的,有两个独立IP,之前尝试性处理时直接用了root作为root的密码,我们可以登录后,修改mysql库user表中的root密码即可:UPDATE user SET password=PASSWORD('新密码') WHERE user='root'; FLUSH PRIVILEGES;,退出然后重新登录就行了。

以上是已知密码的情况,假如我们忘了MySQL的密码又该怎么办呢?没错,上面提到了debian.cnf这个文件中有一个预设用户可以利用,但对更广谱的操作系统而言,假如没有这个用户怎么办?执行service mysql stop停掉服务,然后设定跳过检查mysqld_safe --user=mysql --skip-grant-tables --skip-networking &,登录并使用mysql库:mysql -u root mysql,后面同上面的UPDATE和FLUSH后重启mysql服务即可。

删除文档末表格后空白行或空白页的方法

2015-01-04 • 技术文章

我们有时在使用办公文档软件(如永中文字、Microsoft Word)时经常遇到文末是一个表格的情况,恰恰满一页,造成表格后的一行被放在了下一页中,也就是产生了一个空白页,看上去不爽,打印时还得专门处理一下设置。这个问题的解决方案有如下几种。

微软官方推荐的方案:将表格末自动生成的一个空行的字体大小设定为1,然后将表格后空行的段落行距设定为固定值1磅。显然,该方法有一个比较大的缺陷就是表格末尾要有至少1磅的空白可以利用,否则无效。

此外还有一个比较好的办法是选中最后那个空行末的换行符,打开“字体”对话框,在效果中有一个“隐藏文字”选项,勾选后确定这一行即可消失,整个空白页也会随之消失。如果想让隐藏文字再被看到,点击“段落”中的¶按钮即可控制隐藏字符的隐现。

记一次报案的经历

2014-12-24 • 个人情感

上个月,大约就是去大众点评网参加最后一次技术面试的那一天,我遇到了电话诈骗。对方冒充熟人要我给他汇几千块钱,我以本人账户暂时没有足够余额需要家人跨行汇款给我为由拖住对方,然后去派出所报案了。

到了派出所,我跟窗口的警察说,我拖住了对方,希望能尽快调查好抓住诈骗分子。窗口的警察一脸不屑,反问道,你能把他引到我们派出所来呀。听到这里,我觉得这次报案已经没有什么意义了,警方应该不会立即着手调查,于是对此类案件至关重要的时效性怕是要白白浪费了。虽然,事后有警官找我确认信息,确认立案,但是我已经没什么感觉了,也不觉得会得到侦破。

为什么说这类案件的时效性非常重要呢?首先,犯罪嫌疑人一般不会傻到用自己的身份证去银行开立账户,否则要想查到他太容易了,犯罪嫌疑人一旦得手后会转移资金以防账户被冻结。第二,犯罪嫌疑人使用的手机卡可能是无法确认其真实身份的,否则也太危险了。那么,案件发生后,非常重要的一点就是快速查到犯罪嫌疑人转移资金的途径,转账不太可能,因为太危险,直接取出可能性更大,如果是直接取出那么如果可以看到监控录像是最好了,但犯罪分子通常会专门遮掩自己的面相。另外就是,通信可以使用技术侦查手段,既然拖住了对方,那么未来通信过程中能够对其做跟踪定位对于抓获嫌疑人是极为有利的。

在这次报案经历中,眼看着有利于破案的因素毁在了警方手里。我不清楚是因为繁冗的报案流程需要还是相关人员怠慢了,总之侦破几无望。若为前者,希望以后特事特办,要求时效性的案件要及时进行侦查;若为后者,那么更加令人失望,这也是在本文中没能不吝使用“民警”一词的原因,希望社会主义中国的警察不仅仅是那么一份职业。

Smurf攻击和DNS反射放大攻击

2014-12-10 • 技术文章

最近几天在新闻中频繁提到DNS反射攻击,之前在微博上也经常说起,本文来简单记叙其原理并顺便介绍比较老的Smurf攻击。

Smurf攻击

Smurf攻击是一种比较老的放大攻击方式了。其原理是向网络广播地址发送ICMP请求(如ping),路由将请求转发给该网段下的所有机器。这个ICMP请求的源地址伪造为攻击目标,如果收到请求的机器都响应这个请求,大量的数据就会流向伪造的目标地址,此之谓“放大”。

一台机器发出这样的请求作为DDoS攻击显然压力不足,所以假如有大量的“肉鸡”或者说是僵尸网络服务器可以一起上,每个机器打满网卡速率放出请求,然后再进行一次放大,效果就完全不一样了。不过,现在一般都把路由配置为不转发这种ICMP给网段内的机器,所以这种攻击目前比较少了。

DNS反射放大攻击

DNS反射放大攻击的原理也是类似的。网络上有大量的开放DNS解析服务器,它们会响应来自任何地址的解析请求。我们发出的解析请求长度是很小的,但是收到的结果却是非常大的,尤其是查询某一域名所有类型的DNS记录时,返回的数据量就更大,于是可以利用这些解析服务器来攻击某个目标地址的服务器,而且是利用被控制的机器发起伪造的解析请求,然后解析结果返回给被攻击目标。由于DNS解析一般是UDP请求,不需要握手,源地址属性易于伪造,而且部分“肉鸡”在平时本来就是合法的IP地址,我们很难验证请求的真实性和合法性。DNSSEC是一种可以防止缓存投毒的机制,另外,如果DNS本身抗压能力不行,而且对方请求量过大的话,也会影响到DNS本身的服务。目前此类攻击的规模在数百Gbps级别。

其它形式的放大攻击

NTP:使用MONLIST命令可以获取与目标NTP Server进行过同步的最后600个客户机IP。这意味着,一个很小的请求包,就能获取到大量的活动IP地址组成的连续UDP包。

SNMP:发送GetBulk请求来枚举MIB。

CHARGEN:用于调试和测量的工具协议。无视输入,返回任意字符。UDP协议下收到一个封包就会回一个封包回去;TCP下不断发包给客户端。

总之,放大攻击一般都有以下特点:可以轻易地伪造源地址,响应的数据量大于请求数据量好多倍。

参考资料与扩展阅读

http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack/

http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack/

https://www.us-cert.gov/ncas/alerts/TA13-088A

http://blog.sina.com.cn/s/blog_459861630101b4wf.html

http://drops.wooyun.org/tips/2106

PDF: An Analysis of DrDoS SNMP/NTP/CHARGEN Reflection Attacks

分组计算的SQL设计探讨

2014-11-16 • 技术文章

之前,我在《大学课程基础知识整理:数据库原理》文末留了一个SQL设计的问题。这个题是由某项目的具体业务设计时遇到的问题抽象出来的,对于表中类别列分类别取另一数据列的最值,前些日子开源社区的几位同学也在线上简单讨论了一下。

方案选择

看到这个问题,某同学首先想到了用group by,但这样做显然要先子查询排个序,否则得到的并不一定是最值。使用explain查看执行计划,对于该方案,首先是排序来一遍全表扫描,然后在临时表上处理又是一遍全表扫描,type都是all,没有利用到索引。

另外根据讨论情况综合一种方案,select userid,dat from tbl t where t.logintime = (select max(logintime) from tbl where userid = t.userid),查看执行计划,注意到使用到了索引,子查询只扫描了一条记录,select_type是DEPENDENT SUBQUERY,rows=m,外层查询type是index,rows=n。换句话说子查询执行了n次,子查询执行的次数依赖于外层查询。另外为logintime建立索引,也是一种选择。

从执行计划来看,后一种方案效率更高,实际在业务数据中查询也确实效率高很多。但是在使用依赖于外层查询的子查询时,需要小心一些,不妨看看下面的扩展阅读。

扩展阅读

慎用MySQL子查询,尤其是看到DEPENDENT SUBQUERY标记时