[01:00] <tomreyn> hmm, no 18.04.3 postponement message at https://lists.ubuntu.com/archives/ubuntu-announce/ yet - https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule still says 2019-08-01 - probably tomorrow then
[01:01]  * tomreyn zzz
[01:04] <sarnold> tomreyn: hah, I went looking through #ubuntu-release logs.. got directed to #ubuntu-devel logs .. and the conversation was with *you* :)
[01:05] <sarnold> tomreyn: I read these as suggesting that it'll be *next* week, not today
[01:08] <tomreyn> sarnold: okay, *almost* in bed now ;) so i'm just pointing out that (while i'm aware the release will be delayed, since this was indeed discussed in #ubuntu-devel - i also asked whether there'd be a postponement announcement - and the plan was to send one, but there is none - at least not yet - and the release schedule still states it'll release on the past day.
[01:10] <tomreyn> maybe i'm just nit picking, yould just like to have some (non irc) statement i could pass on.
[01:10] <tomreyn> s/yould just/I would just prefer/
[01:12] <tomreyn> sarnold: and re-reading what you just said here, maybe you're just joking aboiut how you misunderstood something and i'm just too tired to get this. ;-)
[01:12] <tomreyn> either way, bon nuit.
[01:14] <sarnold> tomreyn: good morning :) by the time you read this I'll have asked someone to post somethiong more formal :)
[03:52] <lotuspsychje> good morning to all
[06:53] <lordievader> Good morning
[07:23] <marcoagpinto> Heya!!!
[07:27] <immu> hi....
[07:42] <RikMills> tomreyn: well, it's not now plausible to get the QA done on images for a release before middle of next week IMO, even if release declares the ones being prepared good for testing
[08:02] <lotuspsychje> hey TJ-
[08:03] <lotuspsychje> TJ-: yes, that dmesg was on the flickering boot -23
[08:05] <TJ-> lotuspsychje: ahhh, has tjalt's kernel builds located the issue yet?
[08:05] <lotuspsychje> TJ-: im currently testing Linux Rootbox 5.0.0-rc1 #12 and now learning what bisect is..
[08:05] <TJ-> I'm only here trying to solve a failure of 'systemctl suspend' so I can travel - I'm 1.5 hours behind schedule right now, grrr
[08:14] <lotuspsychje> OerHeks: you fixxed your -23 bug?
[08:14] <OerHeks> lotuspsychje, by booting recovery & using the dpkg option to check packages
[08:15] <lotuspsychje> ok
[08:15] <lotuspsychje> didnt see new users reporting things for now..
[08:15] <lotuspsychje> im still working on mine
[10:27] <jeremy31> lotuspsychje: do you have the flicker without having nomodeset in grub?
[10:27] <lotuspsychje> jeremy31: yes, thats the original issue, update to 5.0.0.23 without nomodeset
[10:28] <lotuspsychje> nomodeset, works without flickering, but backlight dont work then
[10:28] <jeremy31> And you have Intel UHD 620?
[10:29] <lotuspsychje> yes
[10:32] <jeremy31> Not much in the changelog from -21 to -23
[10:33] <lotuspsychje> jeremy31: i went from 4.18 to 5.0.0.23 (hwe)
[10:33] <lotuspsychje> so didnt test -21
[10:33] <lotuspsychje> maybe its all related to kernel 5?
[10:35] <jeremy31> It could be, I have a 620 but am still using 4.15
[10:35] <lotuspsychje> feel free to risk your system :p
[10:36] <jeremy31> I might try 5.0.0-12 and see if it works,, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824216 might be the cause
[10:37] <lotuspsychje> lemme read, looks promising
[10:39] <jeremy31> Got to head to work
[10:39] <lotuspsychje> have fun jeremy31
[12:16] <BluesKaj> Hi folks
[12:22] <tomreyn> sarnold: good morning, and thanks! :)
[12:26] <tomreyn> RikMills: hey there, thanks for your reply. i'm not pushing for a new fixed release date, but it'd be great to see a "it'll have to be later than originally planned", with bonus points for a 3 word explanation, type announcement. right now it's just that the schedules release has not happened, and there's (besides us few who know) no statement to the public on it.
[12:27] <tomreyn> but maybe i'm asking too much. how were delays handled in the past?
[12:27] <tomreyn> (i.e., was there an advisory when there were any?)
[12:33] <marcoagpinto> BluesKaj! tomreyn!!!!! Hello guys!!!!
[12:33] <marcoagpinto> I was brushing my theeth
[12:33] <tomreyn> oh so you do have some left?
[12:34] <marcoagpinto> yes
[12:34] <tomreyn> that's good, and hello.
[12:34] <marcoagpinto> I use special toothpaste
[12:34] <marcoagpinto> :)
[12:34] <tomreyn> "cola neutralizer"
[12:34] <marcoagpinto> and drink special milk with vitamine D and Calcium
[12:34] <marcoagpinto> yes, exactly
[12:35] <marcoagpinto> the only light I usually get is from the computer screen
[12:36] <tomreyn> your efforts are impressive, but you're really runing yourself if you go on like this - don't do it. :-/
[12:37] <marcoagpinto> :(
[12:38] <tomreyn> sleep and walking around in the fresh air are really good, even though i never trusted my parents on that. ;-)
[12:38] <marcoagpinto> :)
[13:28] <marcoagpinto> bbl
[14:12] <RikMills> tomreyn: last time there was an email like this: https://lists.ubuntu.com/archives/ubuntu-release/2019-February/004694.html
[14:12] <RikMills> I have not seen why there is no one this time
[14:13] <tomreyn> hehe, i like the second paragraph (pet bugs).
[14:13] <tomreyn> RikMills: thanks for finding this
[14:14] <RikMills> tomreyn: all I saw frok Adam (infinity) this time on IRC wasL
[14:14] <tomreyn> i think adam worked all night and just needed sleep, and no one else was available
[14:14] <RikMills> [16:21] <infinity> RikMills: [16:21] <infinity> RikMills: It was delayed due to kernel issues, but a notice wasn't sent (yet) for reasons.
[14:14] <tomreyn> ah for reasons, ok.
[14:14] <RikMills> extra bit of copy/paste there, but 'reasons'...
[14:15] <tomreyn> let's wait then. ;)
[14:15] <RikMills> maybe something security? who knows
[14:16] <tomreyn> could be anything, including what his /away message says
[14:17] <RikMills> well at the moment 'dkms modules suddenly asploding' is one bug
[14:18] <tomreyn> while i appreciate it, please don't share internal info with me in case you're just doing so.
[14:19] <RikMills> tomreyn: you are in #ubuntu-release where that was said. its public
[14:19] <tomreyn> oh good :)
[14:19] <tomreyn> i missed it
[14:21] <RikMills> easy done
[14:21]  * RikMills goes back to poking stuff on Eoan
[14:21] <tomreyn> :) thanks
[15:51] <Rojola> hi
[15:52] <Rojola> tomreyn, so, I solved it like this:
[15:52] <Rojola> at first, I installed 'cpanminus'
[15:52] <Rojola> 'git' and 'make' were already installed
[15:52] <Rojola> then I cloned imapsync's github repo
[15:53] <Rojola> now, the cool part is:  when I run "make install" I get a list of missing perl modules
[15:53] <Rojola> and it tells me the exact command I need to install them
[15:53] <Rojola> that's what I needed 'cpanminus' for
[15:54] <Rojola> after that, 'make install'  could work if all dependencies are met
[15:54] <Rojola> I also needed 'libssl-dev' and 'libpar-packer-perl'
[15:55] <Rojola> tomreyn?
[15:56] <lotuspsychje> how can we help you Rojola
[15:56] <Rojola> lotuspsychje, thanks, I am good
[15:56] <Rojola> lotuspsychje, no need for help
[15:57] <Rojola> lotuspsychje, the user tomreyn asked me to explain the solution in here
[15:57] <lotuspsychje> ok mate
[15:58] <tomreyn> Rojola: i'm here, sorry, too much chatting ;)
[15:59] <Rojola> tomreyn, sure, np
[15:59] <tomreyn> Rojola: cool, so you found a solution which works for oyu?
[16:00] <tomreyn> Rojola: i did have a quick look at the ubuntu specific installation instructions for imapsync. it looked doable, if those dependencies were satisfyable.
[16:01] <Rojola> tomreyn, yes the solution works
[16:01] <tomreyn> Rojola: i guess you could alk debian to package this software, but they may require the developer to relicense it under a DFSG-free license
[16:02] <Rojola> tomreyn, I have known imapsync since so, so, so many years... I really wanted to use _this_ tool
[16:02] <Rojola> what's wrong with the license?
[16:02] <Rojola> is it illegal?
[16:02] <Rojola> don't scare me man!
[16:02] <RikMills> tomreyn: https://lists.ubuntu.com/archives/ubuntu-release/2019-August/004787.html
[16:03] <Rojola> I got a really, really stupid question... please bear with me:   After I successfully installed something via "make install"
[16:03] <tomreyn> Rojola: no, no, it's just custom, meaning they need to verify it's compatible with their licensing requirements.
[16:03] <Rojola> can I delete the directory where I have the sources?
[16:03] <Rojola> git clone ....  <== there I get a directory
[16:03] <Rojola> then I "make install" it
[16:04] <Rojola> can I delete the cloned git-directory then?
[16:04] <Rojola> I have been keeping all these directories but I wonder if I need to
[16:04] <tomreyn> RikMills: Thanks so much to you and Dimitry!
[16:04] <tomreyn> *Dimitri
[16:04] <Rojola> tomreyn, would you like to ask people about packing imapsync and contacting the developer?
[16:05] <tomreyn> Rojola: not really, no, you should file a RFP bug (do a web search on this) against debian.
[16:06] <Rojola> would Debian even care what I have to say?
[16:06] <Rojola> I mean, who am I?
[16:06] <tomreyn> it will really need someone to want to make it happen, i.e. someone packaging it. if you know how to do this, file an ITP bug instead.
[16:07] <tomreyn> but a RFP is an option to point out that there is a demand for someone packaging it.
[16:08] <tomreyn> https://wiki.debian.org/RFP
[16:08] <tomreyn> https://wiki.debian.org/ITP
[16:08] <Rojola> thank you tomreyn !
[16:09] <tomreyn> Rojola: you can remove the git repository if you did 'make install' (and are not planning to install updates by updating git and running make install again)
[16:10] <Rojola> thank you tomreyn
[16:10] <RikMills> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919587
[16:10] <tomreyn> you're welcome, Rojola
[16:10] <Rojola> tomreyn, ooooh, too sweet of you!! You just added that?
[16:10] <Rojola> thank you tomreyn
[16:11] <tomreyn> no i did not, read it carefully. also RikMills pointed you to this, not i ;)
[16:25] <wasanzy> I found this after scanning my infected server with ClamAv:
[16:25] <wasanzy> https://paste.debian.net/1094080/
[16:28] <tomreyn> wasanzy: thanks for joining. can you run    sha256sum /var/lib/postgresql/10/main/postgresq1
[16:29] <tomreyn> wasanzy: that's in case it's still there. and did you find out how the system got infected in the first place?
[16:29] <wasanzy> ed3b7209ee905cc5a2a2b33f351511c895ea6913428536b9e162eb487a24528f  /var/lib/postgresql/10/main/postgresq1
[16:30] <tomreyn> https://www.virustotal.com/gui/file/ed3b7209ee905cc5a2a2b33f351511c895ea6913428536b9e162eb487a24528f/detection
[16:30] <wasanzy> tomreyn: am not able to determine how the system got infected yet
[16:30] <tomreyn> so that's "just" the miner, it remains unclear what caused the infection
[16:32] <tomreyn> wasanzy: the fact that the file is located in /var/lib/postgresql/... and the file is owned (i think you said so earlier, better double check this) by system user "postgres" suggests that it may have been stored that as the result of an sql injection
[16:33] <tomreyn> so you should check the softwares which were interacting with the postgresql server on this computer for SQLI vulnerabilities. before you do this, though, also check what you didn't allow remote access to postgresql.
[16:33] <wasanzy> tomreyn: Ok I will do further checks
[16:34] <tomreyn> i'm saying all of this assuming the production server has been taken offline since and you're just anylzing the compromise while someone lese s preparing to bring a replacement system live.
[16:38] <wasanzy> yea the server is no more in production
[16:40] <tomreyn> \o/
[16:43] <tomreyn> wasanzy: see if you have other files in /var/lib/postgresql/10/main/ which were changed recently and may not belong there. you can generate hashes against them and check those against virustotal (without risking to disclose sensible data) by just placing the hash on the url.
[16:44] <tomreyn> to find sql injections in web applications you have running, the most common approach is using "sqlmap". but this is for later, i guess.
[16:44] <tomreyn> you could also use static alaysis utilities if you have their source code available.
[16:46] <tomreyn> ask in ##security if you need more suggestions
[17:13] <wasanzy> ok
[17:13] <wasanzy> tomreyn: sorry I got disconnected
[17:21] <tomreyn> wasanzy: did you see what i wrote, should i repeat? the last line was: ask in ##security if you need more suggestions
[17:21] <wasanzy> <tomreyn: yes I see that
[17:22] <wasanzy> am now scanning the whole system I mean root directory to see if malware is somewhere else too
[17:23] <tomreyn> wasanzy: i assume you mean / and not just /root
[17:23] <wasanzy> yes /
[17:26] <wasanzy> am installing sqlmap on the system
[17:31] <tomreyn> wasanzy: keep in mind there's alwass a chance that AV software may not be able to detect fresh malware. the miner was first submitted to virustotal on Nov 19, 2018, it may not have been detected by AVs for weeks or month (and many still don't detect it)
[17:32] <wasanzy> tomreyn: Yes you are right
[17:32] <tomreyn> wasanzy: sqlmap is for scanning against a live website over a network link. you can certainly do this locally (but don't have to, and thiose applications may behave differently when they see accesses from 127.0.0.1)
[17:33] <wasanzy> ok
[17:33] <wasanzy> let me run it from my Kali Linux then
[17:34] <wasanzy> and one thing is, we don't run php powered web applications on the server
[17:34] <tomreyn> it doesn't need to be PHP
[17:35] <tomreyn> any web application which uses user data to run live requests (SQL) against a DB backend may be affected.,
[17:36] <tomreyn> i mean user input
[17:42] <tomreyn> call for 18.04.3 pre-RC ISO testing https://lists.ubuntu.com/archives/ubuntu-release/2019-August/004788.html
[17:42] <tomreyn> http://iso.qa.ubuntu.com/qatracker/milestones/405/builds
[17:44] <daftykins> :O
[17:54] <wasanzy> Ok good
[17:57] <tomreyn> wasanzy: did you notice that the last charcter of the miner is a "one" (1), not an L (l)? that's a unique identifier (i.,e. we can search the web for similar situations) and here's a cimilar one https://www.postgresql-archive.org/posgresql-log-td6021877.html
[17:58] <tomreyn> wasanzy: i.e. you may have similar records in your postgresql logs in case those still exist.
[17:59] <wasanzy> interesting
[18:00] <tomreyn> the server the malwas was downloaded from there is a cpanel server - which no longer hosts it. this may suggest this was also a compromised system.
[18:01] <tomreyn> s/malwas/malware/
[18:03] <wasanzy> ok
[18:04] <tomreyn> the messages printed there are by wget, which suggests that the attacker was already able to run arbitrary commands at the point when they downloaded the miner.
[18:09] <wasanzy> interestingly, there is no "postgresq1" in any of the logs
[18:10] <tomreyn> it may be encoded.
[18:10] <tomreyn> but you'Re right, it should be there if it was logged the same way as seen at https://www.postgresql-archive.org/posgresql-log-td6021877.html
[18:11] <tomreyn> which postgresql version vwere you running on which ubuntu version, and when was it last updated?
[18:12] <tomreyn> as steve atkins writes on this thread, "It's probably a compromise via postgresql open to the network with insecure settings" - that's my suspicion, too. have you been able to rule this out, yet?
[18:13] <wasanzy> grep -r "postgresq1" /var/log/*
[18:13] <wasanzy> return nothing
[18:13] <tomreyn> does it have logs for this day, though?
[18:14] <wasanzy> yes the postgresql log has logs for yesterday
[18:14] <wasanzy> the system is auto update everyday
[18:14] <tomreyn> and postgresql was installed from ubuntu repositories or elsewhere?
[18:14] <wasanzy> ubuntu repo
[18:15] <tomreyn> which ubuntu version?
[18:15] <wasanzy> running Ubuntu 18.04
[18:15] <wasanzy> Linode cloud
[18:20] <tomreyn> wasanzy: hmm, so 18.04.2 then really? since we assume /var/log/audit/ was overwritten by the attacker, this actually suggests that they had elevated permissions (root access), unless poermissions were incorrectly set there. can you say which ownership and permissions were set at /var/log/audit post compromise?
[18:23] <sarnold> I'd like to make sure wasanzy knows that the safe way forward here is to reinstall from known good media and restore clean data from backups
[18:23] <sarnold> forensics is fun and good but don't pretend you can bring this system back online in any useful way
[18:24] <tomreyn> this made me think we're beyond this point <wasanzy> yea the server is no more in production
[18:25] <sarnold> good good
[18:25] <tomreyn> but it's good you're stressing the need to recover properly
[18:25] <tomreyn> i'm not yet convinced of this ;)
[18:26] <tomreyn> ^ wasanzy: you got a recommendation from a member of the ubuntu security team there. ;)
[18:30] <tomreyn> (hope you don't mind the full disclosure, sarnold)
[18:31] <sarnold> tomreyn: indeed, I don't mind; it's not particularly hidden in any event :)
[18:31] <tomreyn> right
[18:38] <wasanzy> interesting help coming up
[18:41] <wasanzy> sarnold: only two users are permitted to execute sudo su and one user who can run commands with with sudo but any sudo command throws alert
[18:42] <wasanzy> tomreyn: ^^ sorry
[18:45] <wasanzy> root owns the /var/log/auditd
[18:54] <tomreyn> wasanzy: so if you assume the attacker deleted those logs you know what this means.
[18:54] <tomreyn> (where "the attacker" was most likely some fully automated malware)
[18:56] <wasanzy> I assumed the file was tempted with because I could not see yesterday nor any other date entries in the log except today.
[18:57] <tomreyn> wasanzy: this still suggests someone gained root access to tamper with it
[19:00] <wasanzy> this is interesting
[19:21] <lotuspsychje> wb TJ-
[19:22] <TJ-> lotuspsychje: solved your issue yet?
[19:22] <lotuspsychje> TJ-: still bisecting kernels with tjaalton
[19:23] <lotuspsychje> TJ-: i need to kernel param fastboot=0 now too
[19:32] <TJ-> That feeling of deja-vu you get when searching for a bug report that describes an issue you're experiencing, only to find you reported it 18 months ago!!
[19:34] <lotuspsychje> TJ-: i actually found similiar flickering ubuntu bugs
[19:34] <lotuspsychje> jeremy31 also found a kernel 5 bug interesting
[19:35] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824216
[19:35] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1550779
[19:38] <TJ-> lotuspsychje: Doesn't surprise me at all; end of last year/start of this I was in the Intel IRc channel helping someone else with an issue and the development process really struck me as 'through mud at the wall and hope it sticks' - I got the real feeling that no-one really understood the hardware or the driver in-total. In fact I got the feeling Intel deliberately keep the Open-source developers in
[19:38] <TJ-> the dark about core hardware functionality based on their conversations.
[19:39] <TJ-> oops, s/through/throw/
[19:50] <jelly> TJ-, #intel-gfx here on freenode?
[19:51] <TJ-> jelly: I'd have to check it was many months ago
[19:51]  * jelly greps logs for TJ- 
[19:51] <TJ-> jelly: yes, I have a log-file for that channel
[19:53] <jelly> May 22 13:08:52 <--     TJ- (root@2a02:[...]:484) has left #intel-gfx ("WeeChat 1.9.1")
[19:56] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1838818
[19:56] <lotuspsychje> fresh in, we better keep an eye on kernel 5 & graphics
[19:56] <TJ-> we can add this to a similiar harder-to-find regression in iwlwifi too, I still suffer using any kernel later than 4.17
[19:58] <lotuspsychje> out for today, my kernel lost is huge lol
[20:23] <daftykins> a wild TJ- ! \o
[20:25] <daftykins> TJ-: ever seen hdparm get used to set an ATA password, then the one set doesn't work immediately after - and the drive becomes useless? that's the situation i've got!
[20:26] <daftykins> (it was during an attempt at a secure erase of an SSD)
[20:47] <TJ-> daftykins: not seen, but read of, and I *think* I also read of a fix, but it may have been manfufacturer specific
[20:48] <TJ-> daftykins: password was ASCII? how many characters - could it have exceeded the internal length limit in which case you just need to type less characters
[20:49] <daftykins> TJ-: i fed it "blargh" :D
[20:49] <daftykins> from a 14.04.3 live session
[20:50] <TJ-> daftykins: hmmm and what does the kernel log report when trying to unlock it?
[20:51] <daftykins> ah didn't read anything from the log, 14.04.3 gives this annoying sense data error, 14.04.1 just gives an I/O error
[20:51] <daftykins> i read a claim that some kernel broke the function which causes the former
[20:51] <TJ-> well without seeing the logs and what hdparm reports its hard to guess
[20:52] <TJ-> is it possible the SSD coincidentally died due to/during the Secure Erase step?
[20:52] <daftykins> okie dokie, i'll throw some notes together sometime - i've kind of given up on the thing entirely though, fancy a 128GB mSATA drive? ;)
[20:52] <daftykins> ah i didn't get that far, only the password creation
[20:53] <TJ-> is the SSD directly connected on SATA or via a USB bridge ?
[20:53] <daftykins> i have a SATA adapter, i'd anticipate problems with bridge chips
[20:54] <TJ-> whats the make/model of SSD?
[20:54] <daftykins> the drive in question is an OEM SanDisk U100 which came in a Samsung laptop, no surprises both companies don't want to help
[20:54] <daftykins> only desktop support minions who don't know what an ATA password is
[20:55] <TJ-> this one ? https://ssd.userbenchmark.com/SpeedTest/2827/SanDisk-SSD-U100-128GB
[20:56] <daftykins> pretty much
[20:59] <TJ-> could you use this (windows) tool to create the (Linux) bootable USB image to try with?  https://kb.sandisk.com/app/answers/detail/a_id/16678/~/secure-erase-and-sanitize
[20:59] <daftykins> the problem is now that the password is set, the drive is locked
[21:00] <TJ-> I was thinking along the lines that the Sandisk tool might have a way to deal with that
[21:00] <TJ-> something that hdparm isn't aware of
[21:01] <daftykins> at least from in Windows with the drive on a secondary channel, the utility runs a secure erase and some other kind of wipe and claims it worked - but nothing changes... but yeah i could try preparing the bootable media, i suspect it'll be no different
[21:01] <daftykins> i've found and tried many different utilities, some from a DOS environment - everything errors with the password i set
[21:02] <TJ-> is it possible you mistyped ? is the command history in the clear so you can confirm the password you think you set, is the one actually set?
[21:03] <daftykins> i think the 14.04.3 kernel and utility are to blame, nah i definitely had it 100%
[21:04] <TJ-> well as far as I recall hdparm does direct access to the device - I'm not sure the kernel gets involved aside from passing the command/data to the drive
[21:05] <daftykins> hmm, i found a comment that using 16.04 or above's kernel has changed something that ruins the functions
[21:05] <TJ-> really, where's that?
[21:05] <daftykins> ah not sure i can dig it up now, let's have a quick try
[21:11] <daftykins> here's an example of the error 14.04.3 would give...
[21:11] <daftykins> SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00
[21:11] <daftykins> i've chopped the values at the end and those aren't necessarily identical to what i got
[21:12] <daftykins> the drive wasn't frozen at this point, like some results online suggest
[21:15] <TJ-> that missing sense data was after setting the password though?
[21:16] <daftykins> yep, that's on any attempt at unlock since
[21:17] <daftykins> no luck finding the post talking about the kernel/release having an impact
[21:25] <TJ-> the only related report I can find is with a USB bridge, and the solution there was a direct-connect, which you already have https://bbs.archlinux.org/viewtopic.php?id=160476
[21:25] <daftykins> mmm
[21:25] <daftykins> lots talk about unfreezing too, but that also doesn't apply
[22:55] <daftykins> well, having a rough time with a pet health related drama here so i'm heading off early \o