[00:42] hello all ... before my server freezes im detecting this message in logs "TCP Peer: {ip} unexpectedly shrunk window 954892853:954895757 (repaired)" [00:42] any ideas on what it might be? [00:46] is there ubuntu server (latest stable) settings I can implement that make up for slow drives I have battery backed up everything and a UPS and data doesnt change often. So A large cache might be helpful or other settings I dont know of. Thanks for the pointers! [00:49] hikenboot, can you say more? are you losing data to power outages? [00:50] no data is being lost...everything is fine just I notice the VM (uunder esx5i) has slow typing into the ubuntu server guest and also that the admin panel in wordpress is slow responing [00:50] xsl, thats probably normal, what else appears in the log? [00:50] s/responing/responding/ [00:50] hikenboot, ah. What's the VM's config? how much RAM? what's the host box like? [00:51] SpaceBass, after that i only see the reboot it self [00:51] host box only has one hard drive but I have 24 gig of memory for two vms ( a windows 2008 R2 SP1 Domain controller) and (a ubuntu latest stable server running apache and wordpress website) [00:51] Feb 23 05:19:03 andy kernel: [30601.301962] usb 2-1.8: USB disconnect, device number 5 [00:51] Feb 23 05:20:03 andy kernel: imklog 5.8.6, log source = /proc/kmsg started. [00:51] hold on let me see how much memory i have assigned to guest to be sure [00:52] 8 gig to the ubuntu guest [00:52] I have lxcontainers on that server... i'm starting to believe its some sort of misconfiguration ( i'm in a dead end .... :( ) [00:52] 4 virtual cpu's on an 8 core system [00:52] do you guys know if lxcontainers support ext4 as a backend lvm? [00:53] open source guest tools installed [00:53] xsl, that TCP window error is pretty common, but usually triggered by lots of data and too little cache on the NIC?still nothing to worry about. It does make one wonder if the NIC itself may be going bad and causing a panic? but that's a stretch [00:53] but i dont see anything on the logs [00:54] could be a faulty sysctl config? [00:54] hikenboot, sounds like quite the box! and 8gb is plenty (at least enough to avoid input lag) ? you might be on to something re disk lag. [00:54] its weird because i have several servers like this one ... and only this one gives me problems ( tough its the one with the highest load ) [00:55] hikenboot, I'm outta my league past that ? I'd be tempted to research disk caching and your VM provider?and then maybe test with an SSD on the main bus, if for no other reason than to test throughput [00:56] xsl, highest load sounds suspicious? I'd start at the most basic level: new/different ethernet cable, different port on the switch, then maybe confirm correct kernel module for the NIC is loaded, and then maybe different NIC ?if only for trouble shooting [00:57] SpaceBass, i understand... i already requested a hardware test and the ISP says its all ok [00:57] its a rented server [00:57] xsl, oh wow, doubly complicated in that case. [00:58] i'm so lost that i'm starting to doubt my setup ... [00:58] open files problem ... maybe disk out of inodes? [00:58] but could not be... that way it didnt hang [00:59] i have separate partitions [00:59] if you were out of inodes, it'd throw errors in the log long before a crash [01:00] xsl, can you throttle the traffic to see if it increases uptime? [01:01] i have to check how to do that ... this is a high load webserver [01:01] hikenboot, the input delay is suspicious ? with that kind of ram and horsepower, it does sound like disk lag. But I'm not aware of any settings to tine that (though I'm sure some exist). [01:02] xsl, maybe on the router, upstream? also, confirm the basics like the NIC in full duplex 100 or 1000 mbs mode [01:02] and the proof that it rly hangs is that the software raid ... needs to rebuild sometime [01:02] SpaceBass, thx for the tips ... i'm gonna try and see what i can do about the nic [01:03] xsl, good luck?I'm curious to know what you learn [01:03] xsl, woah,?software raid? mdadmin? [01:03] i will report it... its been a mysterious issue to solf [01:03] yes [01:04] xsl, gig ethernet? [01:04] yes [01:04] wonder if you are flooding the write buffer on the software raid [01:05] whats new to me.. hmmm [01:05] how can i check that? [01:05] used to happen to me w/ a software raid 5 all the time. [01:05] this one is raid1 [01:06] so ... now im thinking... maybe i pushed the nofiles too high... [01:07] that could do it [01:07] in each container i have like ... 65536 [01:07] for hard limit of nginx user [01:07] for mysql user [01:07] for php user [01:08] and the default is 1024 [01:08] have seen systems with 75000, so 65000 doesn't seem too high, but that could very well be it [01:09] i have like 18G of ram .. and its allways at 30% of its capacity, couldn't i use ram to tweak this out? [01:10] you could tune mysql to use more ram [01:11] assuming it's DB writes thats the issue [01:12] i'm using a Innodb buffer pool size of 6Gb [01:12] you might be right [01:12] i'm pushing the disks [01:14] could it be heat? [01:14] are your running lm-sensors ? [01:14] and i have innodb_flush_log_at_trx_commit=1 ... maybe i should set it to 2 [01:14] no, but i can install it [01:15] I had an overheating issue for a while?set up a cron to push CPU temps to my iPhone every 15 mins (if over critical)? ended up buying a $15 fan off amazon and it solved the problem. [01:16] well this is in a rented server, i want to believe that they have a good ventilation [01:16] 2 is each commit, right? [01:16] but non the less.. its a good thing to keep track [01:17] yesterday it rebooted itself .. maybe its rly heat [01:17] those drives could be cranking out some heat [01:19] i have noted down all the ideas you gave me ... its been rly helpfull ... i will tell you my findings [01:19] thx [01:21] in fairness, I'm no expert. But enjoyed thinking through the troubleshooting. [01:21] keep us posted! [01:21] sure ty once again === paddymahoney1 is now known as paddymahoney [02:03] if hdparm shows fast speeds (e.g around 100MB/s) but cp etc is ridiculously slow (1MB/s), what are the possible reasons? === paddymahoney1 is now known as paddymahoney === sweettea is now known as Guest48399 [11:56] Hey guys. I hope someones around because I need some help. Not as in my system is about to explode but post recovery forensics to determine what caused a server issue. I have some theories and I have what data I thought to collect prior to the reboot. I don't know where to begin other then I guess explain the situation [11:56] we have a Linux firewall we use in production, in a rack at the data center. It's actually one of two which provides high availability via conntrackd [11:57] the server stopped accepting ssh requests mid Nov. It showed the port was open and sshd actually gave a error which I don't have in front of right now but I'll pull that up in a minute [11:57] anyways, I went to the data center the other day and I saw the server clearly had a issue [11:58] it's unix load average was 7000+ [11:58] I guess without the error, no fun [11:58] oops [11:58] that's a bit ;) [11:58] the error isn't relavent but [11:58] yeah... [11:58] so as I was saying [11:58] I did some pre-reboot checks and I found one of the main causes seemed to be cron [11:58] high load is usually because of threads hanging in D state, because of bad i/o [11:58] oh and by the way the high load is what causes the error on ssh but ssh isn't the problem here [11:59] which is the case [11:59] and I am suspecting this may be driver related [11:59] at first I thought it was batched cron jobs [11:59] check if processes are in D state [11:59] that is - have you rebooted it yet? [11:59] but then I noticed we had some sshd instances that were also hung and netstat said they were in wait close I believe it was but they have been hung for several months [12:00] RoyK: I did but I saved a lot of stats prior and yes @ d state [12:00] which processes were in D state? [12:00] which is making me suspect it's a driver issue. If sshd is hung on a tcp close for several months... well it makes me think it is in D waiting on the NIC to realease the uninterupptable lock [12:01] many, let me pull up the PS log I did before the reboot [12:01] I've never seen D state be network related [12:01] always disk related the times I've seen it climb [12:02] but I don't know the internals well enough to say for sure [12:02] also, did you save dmesg output? [12:02] and df? [12:02] well I don't want to sound bias but we had some network issues with the broadcom nics when we deployed these servers prior to upgrading the driver from the broadcom site [12:02] it's using bridge on bond [12:02] maswan: df??? [12:02] RoyK: yes, filesystems don't always play nice when you fill them up [12:03] maswan: I wish I did but I just pulled copies of the dmesg log as well as others from the server now and this server had been in this state for several months now [12:03] RoyK: a full /var/log could stick lots of processes in D [12:03] maswan: erm - a full filesystem making load exceed 7k? never seen that ;) [12:03] maswan: why? [12:03] they get an error writing to disk [12:04] if the filesystem is full [12:04] RoyK: Not necessarily [12:04] they aren't put in d state [12:04] RoyK: Sometimes they just get stuck instead [12:04] I don't think the FS is full but let me check. I also note that the server seemed very responsive when I logged in via the console despite the 7000+ PIDs and load avg [12:04] I'd love to see that demonstrated [12:04] RoyK: xfs is nutorious for that, but can happen to other filesystems too [12:04] no xfs [12:05] RoyK: Only happens in certain circumstances, but we see it happen a couple of times per year [12:05] maswan: got a reference for that? [12:05] df is good [12:05] nothing listed above 10% usage [12:05] maswan: I've never seen that... [12:05] now let me look at the PS file as RoyK asked which procs were in D [12:06] and I know cron has 7000+ procs where most were in D but don't know what else [12:06] jetole: that usually means cron is trying to write to a dangling filesystem. I've seen that with NFS [12:07] then it's stuck in D state and can't be killed until the I/O transaction is completed [12:07] meaning *high* load may occur [12:09] RoyK: but sshd hung while waiting for a tcp close since Nov? [12:09] jetole: do you have dmesg output? [12:09] RoyK: when most allocation groups are full and you do many concurrent writes the last few blocks might become wedged instead. "xfs full filesystem hang" seem to find some of those refernces [12:10] maswan: it seems like a very rare case - still, this isn't xfs, as jetole said. [12:10] I don't think this server has nfs but lets go back to which procs. This is a big PS file as I used ps -o x,x,x,x,x,x,x,x,x,x,x,x specifying every little detail from the ps man page I could think might be important. does anyone know the awk syntax for multiple columns? I typically only use it for one column [12:10] RoyK: one thing at a time here. I'm only human [12:10] dmesg? [12:10] so dmesg first? ok [12:10] one min [12:12] well... [12:13] the last dmesg seems to be wrote at 44.67xxxxx on the one saved to /var/log/dmesg. I wish I got the live one but this looks like we have bnx2 issues already [12:13] ... or not. It looks like it's writing the allocations [12:13] irq allocations. [12:13] my mistake [12:13] @ RoyK [12:14] will need the live one to see the errors [12:14] the system has been rebooted already [12:14] iirc /var/log/dmesg is just the one from the bootup [12:14] it may be [12:14] one sec and let me tell you what I have [12:14] it is [12:14] just checked [12:16] I have lsmod, lspci, lsof, ps with the following columns: PID,PPID,STARTED,S,BLOCKED,CAUGHT,CLS,TIME,F,IGNORED,LWP,NI,NLWP,PENDING,PGID,PRI,PSR,RSS,SCH,SESS,RSS,SZ,STACKP,STAT,SZ,TT,VSZ,WCHAN,USER,GROUP,CMD,CMD [12:17] I also have logs from newest to oldest pre log rotate for: conntrackd, dmesg, kern, messages, syslog [12:18] still doesn't help, since what's needed, is the live dmesg at the time of the problem [12:18] I guess I/O was hanging [12:18] that is, the disk or subsystem [12:19] so you're saying I'll never be able to figure it out since I don't have the dmesg? you don't think syslog or lsof may hold some clues? it was in this state from Oct 8th until last night [12:19] I'm skeptical [12:19] on disk [12:19] also, the system was booted on apr 2nd and didn't start to have these back logged / hung procs till oct 8th [12:20] pastebin the syslog (or put it somewhere) [12:20] I really, really want to [12:20] if I/O was hanging, this will probably happen again [12:20] but [12:20] this is corporate [12:20] I can't [12:20] didn't you say this was one of two in a cluster? [12:20] I could be tarred, feathered and hung if I did [12:21] RoyK: it will probably happen again but it took 7 months before it started and yes @ one of two [12:21] jetole: there's no way of finding a lost dmesg. period. so if there's nothing in the logs, there's nothing in the logs [12:21] * RoyK thinks jetole will remember dmesg next time [12:22] RoyK: who says there's nothing in the logs [12:22] well, post the logs [12:22] I'm just starting forensics now. I'm hoping something is in the logs [12:22] I can scan through them [12:22] I wish I could but I can't. I'm sorry. I just can't. Appreciate any hints you can give though since this is a lot of logs [12:23] then use egrep -v 'unimportant|blah|blah' logfile [12:24] and you'll end up with whatever you don't understand, which may be interesting [12:24] but if processes are stuck in D state, they *hang* and can't write to logs [12:24] they won't notice they're hanging [12:24] yeah I'm about to do something similar. I just changed to the syslog dir and ran while read file; do cat "$file" >> master.syslog; done < <(ls -1 | tac) # [12:24] so you probably won't find anything [12:24] about to start vim'ing the master file and :g /pattern/d for all unimportant [12:25] oh [12:25] ... well that sucks [12:25] just wait [12:25] monitor the server regularly [12:25] yeah I'm also going to start writing a montoring script this weekend to help us catch this earlier next time unless I can prove what the failure is first [12:25] use icinga or something to generate alerts if the load gets too high [12:26] right [12:26] * jetole prefers nagios but I get the point [12:28] I'm gonna go hop in the shower. I'll be back in a bit === highvolt1ge is now known as highvoltage [12:56] RoyK: I had 20 minutes to collect this information before I had to perform a scheduled and planned fail over and reboot. We just recently found out about this issue and while we use Nagios, this server is... I don't know how to phrase it without breaking NDA's so let's just say a different class then the rest but in the future it's going to be added to nagios. Anyways, I had 20 minutes where I had attempted to somehow ... [12:56] ... recover the server before the reboot and during the last 5 mins when I realized this wasn't possible, off the top of my head I thought what do I need to save before the reboot, let's get it. Anyways, yes, I'll remember dmesg last time but this was just a different situation then you may be used to so please don't be too quick to judge [12:57] setup syslog to log to a different server [12:58] we will [12:58] the kernel log should hold whatever comes to dmesg [12:58] like I said, it's hard to explain but not in your typical class of how we keep servers normally [12:58] it's kind of new to us to access it but not new as in just been deployed. It's complex [12:58] and NDA's [13:00] ok [13:01] I know [13:01] I wish I could say more but I can't [13:01] * jetole sighs [13:01] joy to corporate politics but they do keep the pay checks comming :-) [13:48] hi [13:48] how can I found file on flashplayer [13:49] lsof!grep flash === nixon is now known as Guest14856 === Guest14856 is now known as n1xon [16:21] hello all, i cannot find the /sys/block/md0/md/stripe_cache_size file .. is this been removed ? how will i know the stripe cache size of my mdadm device? [16:22] what linux version? [16:23] works for my machines - on ubuntu 12.04 or later [16:25] i have ubuntu 12.04... weird [16:25] Description: Ubuntu 12.04.2 LTS [16:26] cat /sys/block/md1/md/stripe_cache_size [16:26] cat: /sys/block/md1/md/stripe_cache_size: No such file or directory [16:26] it was not md0 sorry ... i want the second partition of the disks [16:26] that is built into a raid1 [16:38] xsl: do you have anything under /sys/block? [16:38] and is your md dev named md1? [16:39] pastebin /dev/mdstats [16:40] pastebin /dev/mdstat even [16:47] http://pastebin.com/KGYGgjUS [16:47] ty RoyK for the time [16:48] <_jfb> RoyK are you around?? [16:49] * RoyK is [16:49] _jfb: long time no see :) [16:50] <_jfb> RoyK: indeed! [16:50] <_jfb> busy days! You? [16:50] well, somewhat busy, but I'm not sweathing [16:51] <_jfb> my home theater PC was just hacked!!! We were just sitting here and the mouse started moving around, they opened a browser and pointed to ip2location.com before I could shut it off... the IP (looking at my router) is coming from Egypt. Suggestions? What the F%#$ to do to be sure my home network is 'cleased'?? :o [16:52] <_jfb> cleansed... [16:52] <_jfb> I've taken that computer offline for now, but our others are still online... [16:53] rkhunter and chkrootkit is a good start [16:53] if the box is rooted, well, reinstall it - you never know what they left [16:54] oh, in terms of rooting, check out this book - it's just *brilliant* http://craphound.com/rotn/ [16:54] comes in dead tree versions too [16:55] _jfb: any windows machines on that network? [16:55] <_jfb> we don't know for how long they've been here... so yes, there's one. [16:56] check last -10 for unknown ssh logins [16:56] check for rootkits [16:56] check the system logs [16:56] in that order, usually [16:56] <_jfb> what do you mean if the box is rooted? The user that was logged on has sudo. [16:57] use rkhunter *and* chkrootkit to check if there's a rootkit around [16:57] rootkits will let the intruder access the system without futher logins [16:58] if the account used had or has sudo access without password, better reinstall the box [16:58] <_jfb> ok. [16:59] <_jfb> freaking annoying. [16:59] I know [16:59] Do you have remote desktop enabled, and have the port for it forwarded from your router? [16:59] <_jfb> I'll take it as a learning experience. [16:59] _jfb, do you use java on your system? [17:00] i have a windows server 2003 box with an ntfs formatted raid5 array on a softraid card. is there a way to assemble the array in ubuntu and mount it? [17:00] _jfb: first machine rooted is always inconvenient [17:00] <_jfb> I have a router port forwarding to ssh port [17:00] <_jfb> xsl: yes, java was recently installed... in fact, I think for some remote android ap I was playing with! [17:00] java doesn't open new ports [17:01] and the router in front should stop access unless you browse from it [17:01] java executes anything you want :P [17:01] there have been several exploits on java [17:01] _jfb: and your'e sure no-one else in the house might have messed around with your remote android app? [17:01] it can log keystrokes [17:01] send to hacker [17:01] and then ... [17:01] you get the picture [17:02] xsl: not unless you browse from the system [17:02] dont allow plain text passwords on your ssh .. user rsa certs [17:02] s/user/use [17:02] xsl: "plaintext" on ssh is rather safe if your passwords are good [17:02] RoyK, not necessarly.. you can visit a website that offers "free something" and your being compromised [17:03] passwords are easy to get logged [17:03] xsl: erm - you have to browse from that server for that to work [17:03] or perhaps use the same username and password for that service [17:03] <_jfb> funkyHat: certain. [17:04] which means you're doing something stupid [17:04] RoyK: xsl is talking about a java web applet on the client machine logging keystrokes [17:04] can really a web applet log keystrokes? [17:04] its very common these days [17:05] <_jfb> funkyHat: RoyK: xsl: fearing I may have done "something stupid"... carelessly playing around looking for these android remotes. [17:05] <_jfb> was feeling a little suspicious at times. [17:06] its only stupid if you knew better at the time and did it anyway [17:06] i never install android apps that have only "2 or 3" reviews [17:06] _jfb: did you find a rootkit? [17:07] if even a coder on CM project was caught loggin stuff... imagine people that give away "game cheats for android games" "free very good apps that dotn have ads" [17:07] if you use the simple clamav you might find virus on your temporary files [17:07] _jfb: as others have said, the safest thing to do is reinstall. You might find that something quite benign went on though [17:07] firefoxx or chromium or whatever [17:08] if you dont reinstall you will never be 100% sure... trust me .. the first time is a killer one :D [17:08] and using RSA files to auth yourself is a good idea ... it prevents the need to install fail2ban or something [17:09] for ssh i mean [17:10] RoyK, did you take a look at http://pastebin.com/KGYGgjUS ? [17:10] and i'm using Ubuntu 12.04 [17:12] xsl: sorry - don't know [17:12] <_jfb> Searching for suspicious files and dirs, it may take a while... The following suspicious files and directories were found: [17:13] <_jfb> /usr/lib/jvm/.java-1.6.0-openjdk-amd64.jinfo /usr/lib/pymodules/python2.7/.path [17:13] <_jfb> result of chkroot. [17:13] first thing :( imho dont use openjdk .. and install oracle java 7 [17:16] <_jfb> and rkhunter: [17:16] <_jfb> /usr/bin/whoami [ OK ] [17:16] <_jfb> /usr/bin/unhide.rb [ Warning ] [17:16] <_jfb> /usr/bin/mawk [ OK ] [17:23] unhide is from a package you have installed [17:24] (hopefully) [17:25] _jfb: for your new setup, use fail2ban or perhaps denyhosts to block ssh connection attempts [17:25] or use key-based login [17:25] :) [17:25] the latter is more secure, but doesn't allow you to login from everywhere [17:25] <_jfb> yes, I guess key based ... [17:26] just have your key with a passphrase in a USB disk and you will be fine [17:26] we have some hosts at work requiring both key and password [17:26] that's pretty secure [17:28] RequiredAuthentications2 publickey,password [17:28] put that in sshd_config [17:29] that way he needs to have both auth to login [17:29] nice [17:29] <_jfb> This hurts! What a pain it's going to be... :/ [17:29] _jfb: first time rooted? :) [17:29] <_jfb> yup. [17:30] it hurts badly, but you learn a bit from it [17:30] the biggest pain will be that your going to start building the new server... and you wanna harden each step :) [17:30] <_jfb> I've always been a little suspicious of the level of Paul's security... but I guess now I understand! [17:30] <_jfb> yup. [17:31] hehehe [17:31] I guess Paul has had a box rooted, then [17:32] <_jfb> hehe, perhaps. One thing for certain, he's going to enjoy hearing about this! [17:32] probably ;) [17:33] I guess you made two mistakes [17:33] one: a bad password, or someone sniffed it [17:33] two: sudo without password [17:34] RoyK, that file i was chasing at .. does not exist on raid0 or raid1 [17:34] its for raid5 and raid6 [17:34] <_jfb> three: installing all these stupid android remotes... I'm pretty convinced. [17:34] xsl: ah - that makes sense [17:34] i need to increase write buffer for my mdadm devices i have a mysql server with a large innodb pool and my server freezes each 2 days :( [17:34] xsl: I only have raid6 here [17:35] im thinking its a disk problem since i dont have nothing ( rly nothing ) on my logs [17:35] xsl: the main issue there, is that you're using mysql ;) [17:35] lol [17:35] i dont know that much of postgres [17:35] it works far better [17:35] sql syntax is about the same [17:36] and i used a online tool from percona website... and i believe they push too much out of the hardware... and i dont have a raid controler .. its 2 disks doing all the job [17:36] well the problem is i dont know how to administer it that well [17:36] mysql i know all the syntax to create, view, bla bla bla [17:37] give permissions, take, etc... [17:37] mysql is a pile of * [17:37] and this is from a community of 1000 concurrent users accessing a ipb forum ... [17:37] well [17:37] mysql works well for reads [17:38] this has alot of writes [17:38] but don't use mysql in something that uses transactional databases [17:38] just my opinion [17:38] postgresql is faster for various workloads [17:38] mysql for read-mostly [17:39] and if you're just using simple databases without stored procedures or other hacks, moving to psql will be easy [17:42] i will take a look in to it [17:42] since i have my server with lxcontainers and each has its own software.. like a nginx.lxc php.lxc mysql.lxc [17:42] i can create a container and migrate the data [17:43] then i will just change in the php.lxc with php-fpm the socket and ip of the data [17:43] postgres uses the system buffer for caching [17:43] instead of allocating memory of its own [17:43] that helps out a bit [17:43] _jfb: what did those android remotes do? [17:43] have you tried linux containers and running postgres inside of them ? [17:44] no, but since postgres leaves the OS to do the caching, I'm pretty sure it will perform better than the dedicated memory caching in mysql [17:44] s/leaves the/leaves to the/ [18:37] <_jfb> RoyK: let me access ubuntu using my phone... [18:37] <_jfb> via a java server. [18:37] ok [18:37] was that open from the internet? [18:37] <_jfb> no. [18:37] then that shouldn't be the problem, really [18:38] <_jfb> but it required jre/java... so who knows what was lurking. [18:38] well, java doesn't open any ports [18:38] <_jfb> well, like I said, I don't *know* that it wasn't open. [18:38] and so far you have said only ssh was open [18:38] in the router [18:38] <_jfb> What was weird, is we were just sitting here... and the mouse started to move. [18:38] <_jfb> yes, that's correct. [18:39] <_jfb> one port on my router directing to 22 [18:39] <_jfb> on this box. [18:39] perhaps someone pulled your leg? [18:39] <_jfb> ?? [18:40] <_jfb> my two year old son? [18:40] it's rather uncommon for a hacker to engage in interactive takeover of a system [18:40] <_jfb> like I was saying, then they opened a browser (chrome) and opened the url: ip2location [18:41] not a javascript doing that? [18:41] <_jfb> yes, probably not a very savvy hacker -- maybe just a kid messing around... but freaky none the less. [18:43] <_jfb> I don't think javascript can move a mouse around or launch two seperate browsers (they tried firefox first, but it started updating)... then they chose chrome [18:43] <_jfb> like I said, we were using the box, it just happened that we were sitting here and had our tv on (the monitor)... [18:44] <_jfb> anyway, definitely going to scrub this box. [18:48] _jfb: did you see the same behaviour from a different client? [18:49] might be your mac is rooted [19:01] <_jfb> RoyK: what do you mean mac? [19:02] <_jfb> I've never had anything like this happen before... [19:02] mac address [19:02] <_jfb> how can a mac address be rooted? [19:03] <_jfb> RoyK: back to your comment about it being 'uncommon', now I wish I had let them keep playing... just to see what they were up to ;) [19:04] <_jfb> the one fortunate thing of all this, it wouldn't be too easy to connect that box to me. [19:04] _jfb, you have X forward on in you sshd? [19:04] *your [19:05] thats enough to "move your mouse" and "see your desktop" [19:05] but to be honest... if an hacker is good enough to root you.. he does not need to move the mouse to check a website to know from where is your connection [19:05] gtg [19:06] no chance x forward would make it though ssh without authentication [19:06] <_jfb> RoyK: what did you mean that my mac might be rooted? [19:08] it seems unlikely that the server with only ssh access in should be compromised [19:09] <_jfb> so you think my router is compromised? [19:10] <_jfb> I'm not following... [19:14] no [19:15] just check last -10 [19:15] or -100 [19:15] on that server === marahin is now known as system === system is now known as marahin [23:58] hello, i was wondering how you add permissions to a user to edit a file say the user is username@localhost and the dir is /example [23:59] or i mean edit a directory