| === zz_DenBeiren is now known as DenBeiren | ||
| === ming is now known as Guest47081 | ||
| === sl0wz is now known as slowz | ||
| === slowz is now known as Guest99271 | ||
| === markthomas is now known as markthomas|away | ||
| === athairus is now known as athairuzzz | ||
| === wojdev_ is now known as wojdev | ||
| jamespage | gnuoy, python-logutilsLiam Young <liam.young@canonical.com> (James Page <james.page@ubuntu.com>) | 10:23 |
|---|---|---|
| jamespage | showing up on my merge report for wily if you want todo that | 10:23 |
| gnuoy | jamespage, ack | 10:24 |
| === Lcawte|Away is now known as Lcawte | ||
| zzxc | Hey. Does anyone know if its possible to have mutliple machines on the same Subdomain, where the url path determines wheres to which machine the connection goes? | 13:24 |
| roaksoax | exit | 13:33 |
| zzxc | roaksoax: I think you may have a slash. | 13:35 |
| smoser | strikov, around ? | 13:41 |
| strikov | smoser: yep | 13:41 |
| smoser | it seems that multipath might hav efoobarred some stuff | 13:41 |
| smoser | getting a console log for you just a minute. | 13:41 |
| strikov | smoser: i wonder if this machine has multipath or not? | 13:58 |
| smoser | $ PS1="$ " | 13:58 |
| smoser | $ for d in /dev/sda /dev/sdb; do echo "$d:" $(sudo /lib/udev/scsi_id --replace-whitespace --whitelisted --device=$d); done | 13:58 |
| smoser | /dev/sda: 35000c5001feb99f0 | 13:58 |
| smoser | /dev/sdb: 35000c5001feb99f0 | 13:58 |
| smoser | it does not have mlutipath | 13:58 |
| smoser | but it is identified as such. because we have the same scsi_ids | 13:58 |
| smoser | nice, eh? | 13:58 |
| strikov | smoser: such a naming is not multipath-friendly at all; i don't mean curtin-multipath but multipath in general; | 14:00 |
| smoser | right | 14:00 |
| smoser | interestingly.. | 14:00 |
| strikov | smoser: i suspect that if you manually install multipath-tools there machine won't boot | 14:00 |
| smoser | if i drop hte '--whitelisted' flag, i get '' | 14:00 |
| smoser | strikov, yeah, its completely a bug there. | 14:00 |
| smoser | strikov, '--whitelisted' | 14:01 |
| smoser | --whitelisted threat device as whitelisted | 14:01 |
| strikov | smoser: 'The --whitelisted option must be specified on the command line or in the scsi_id configuration file for scsi_id to generate any output.' | 14:01 |
| smoser | where'd you come up with that flag. | 14:01 |
| smoser | ? | 14:02 |
| smoser | really? where did you see that | 14:02 |
| strikov | smoser: http://linux.die.net/man/8/scsi_id | 14:02 |
| smoser | strikov, i think back to blkid then. | 14:02 |
| smoser | we created a root filesystem on a device | 14:03 |
| smoser | outside of UUID collision if we see other devices with that UUID, we can assume multipath | 14:03 |
| smoser | right? | 14:03 |
| strikov | smoser: raid1 | 14:04 |
| strikov | smoser: scsi_id used with --whitelisted inside 60-persistent-storage | 14:04 |
| smoser | well, we a.) dont set up raid1 | 14:04 |
| strikov | smoser: i probably took it from there | 14:04 |
| smoser | b.) would know if we did | 14:04 |
| smoser | right? | 14:05 |
| strikov | smoser: we don't create multipath as well, system has it by default; same with raid1 | 14:05 |
| strikov | smoser: we may mix some additional bytes into what we get from scsi_id | 14:08 |
| smoser | smb, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1462530 | 14:08 |
| smoser | what did you mean there ? | 14:08 |
| smoser | you want multipath -ll output ? | 14:08 |
| smoser | no iscsi in place. | 14:08 |
| strikov | smoser: not me, smb | 14:08 |
| smoser | these are power8 systems like yours that have multipath on internal devices | 14:08 |
| smoser | strikov, that suggestion might work also. | 14:09 |
| strikov | smoser: oh, sorry, i misread the nick :) | 14:09 |
| smb | smoser, whatever info to know what the environment looks like | 14:09 |
| smb | smoser, at least multipath -ll to see how the devices got arranged | 14:10 |
| smoser | smb, sure. i can do that. i suspect if you try this on the power8 system that you have access too, you'lll see it also | 14:10 |
| smoser | smb, i'm pretty sure you have a power8 system, right? if not i can get you to that one | 14:11 |
| smb | smoser, we should have one but I have not yet had need for access | 14:11 |
| smb | and then I would not know whether the hw is the same and resulting whether things look the same | 14:12 |
| strikov | smoser: okay, i think i know what's happening with that machines; i just read that scsi_id may return non-unique serial numbers for ATA/SATA devices; | 14:13 |
| strikov | smoser: could you verify that hdds are indeed sata there? | 14:13 |
| smoser | strikov, opened bug | 14:15 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1463046 | 14:15 |
| smoser | strikov, is lshw enough for you? | 14:16 |
| strikov | smoser: i think so | 14:16 |
| smoser | attached to bug. | 14:16 |
| strikov | smoser: attach it to the bug please | 14:16 |
| strikov | ack | 14:16 |
| smoser | smb, all the power8 have these | 14:17 |
| smb | strikov, hm... not sure but I thought the udev rules at least limited multipath to bus scsi but I would need to look | 14:19 |
| strikov | smb: what i see is pretty strange, disk is 'ATA disk' but attached to 'scsi' bus as 'emulated' | 14:20 |
| strikov | smb: i have no idea what it means | 14:20 |
| smb | ah doh!. Yeah libata making all disks scsi-like | 14:21 |
| strikov | smb: so we basically need to fetch the real nature of the device somehow | 14:24 |
| strikov | smb: because scsi_id output for ata devices is not unique | 14:25 |
| smb | strikov, one should how it would be. at least here it is different for those devices I could try quickly | 14:26 |
| smb | I am not sure what is taken to get the number I see | 14:26 |
| smoser | strikov, so smb tells me that you can have the IO use both links | 14:32 |
| smoser | in multipath. that'd be a useful thing. | 14:33 |
| strikov | smoser: smb: you mean some options to add to the default config? | 14:33 |
| smoser | strikov, yeah. | 14:34 |
| smoser | man multipath.conf | 14:34 |
| smb | strikov, yep to change grouping to multibus | 14:34 |
| Teduardo | Has anyone gotten apache2.4 logging to syslog properly for errorlog? | 14:34 |
| smoser | it *says* its the defualt, but smb disabrees | 14:34 |
| smoser | just have to set defaults path_grouping_policy = multibus | 14:34 |
| Teduardo | doesnt seem to work at all for me | 14:34 |
| strikov | smoser: what does multibus mean, i didn't get it | 14:38 |
| strikov | smb: ^^ | 14:38 |
| smb | strikov, means all paths are usable at the same time | 14:39 |
| smb | Which is not always true | 14:39 |
| smb | Same storage servers need manual scsi magic to switch active paths | 14:39 |
| strikov | smb: are you sure about it? i read it as grouping all disks into a single mpath0? | 14:39 |
| smb | Or need time | 14:39 |
| strikov | smb: you mean path_grouping_policy = multibus, right? | 14:40 |
| smb | strikov, yes, it depends on multipath -l, the multibus layout shows all sd* devices under the same path group | 14:40 |
| smb | while failover shows multiple path groups with one device in them | 14:40 |
| smb | strikov, whatever the man page says. I read that myself to be sure :) | 14:40 |
| strikov | smb: i just can't figure out if it is related to performance only or it changes device naming | 14:42 |
| strikov | smb: let's say we have two multipath pairs | 14:42 |
| strikov | smb: will it merge them into a single /dev/mpath (which is wrong) or not? | 14:43 |
| smb | strikov, it will always be a one mpath device but the way that is created differs | 14:43 |
| strikov | smb: oh, so we can't have two for two separate pairs of disks? | 14:44 |
| smb | strikov, I can give more explanation later. I have to bail out for a bit right now (real world appointments and such) | 14:45 |
| strikov | smb: ack, ping me when you return please | 14:45 |
| strikov | smoser: could you run scsi_id with additional -p 0x80 option please | 14:45 |
| === mrt333_ is now known as mrt333 | ||
| smoser | $ for d in /dev/sda /dev/sdb; do echo "$d:" $(sudo /lib/udev/scsi_id --replace-whitespace --whitelisted -p 0x80 --device=$d); done | 14:49 |
| smoser | /dev/sda: SATA_SMvDi02lGylQfF1qi02lGylQfF1qfjGL9Go6 | 14:49 |
| smoser | /dev/sdb: SATA_SMvDkoWziOynRqDDkoWziOynRqDDMpLqadMA | 14:49 |
| smoser | strikov, ^ | 14:49 |
| strikov | smoser: interesting | 14:52 |
| strikov | smoser: i really don't want to disturb you :( but could you get the same info from the power machine? | 14:52 |
| strikov | smoser: from real multipath i mean | 14:53 |
| === strikov is now known as strikov-lunch | ||
| smoser | strikov-lunch, lk. | 15:01 |
| strikov-lunch | smoser: i read that ata devices need to be identified by the id from page 0x80 and i think that we may read the same page for scsi as well | 15:02 |
| smoser | # for d in /dev/sd?; do echo "$d:" $(/lib/udev/scsi_id --replace-w | 15:02 |
| smoser | hitespace --whitelisted -p 0x80 --device=$d); done /dev/sda: | 15:02 |
| smoser | /dev/sdb: | 15:02 |
| smoser | /dev/sdc: | 15:02 |
| smoser | /dev/sdd: | 15:02 |
| smoser | /dev/sde: | 15:02 |
| smoser | /dev/sdf: | 15:02 |
| smoser | /dev/sdg: | 15:02 |
| smoser | /dev/sdh: | 15:02 |
| strikov-lunch | smoser: okay | 15:02 |
| smoser | /dev/sdi: | 15:02 |
| smoser | /dev/sdj: | 15:02 |
| smoser | /dev/sdk: | 15:02 |
| smoser | /dev/sdl: | 15:02 |
| smoser | /dev/sdm: SIET_VIRTUAL-DISK | 15:02 |
| strikov-lunch | smoser: okay, so scsi disks don't have such info at all | 15:03 |
| strikov-lunch | smoser: so my proposal is to create scsi_id by combining 0x83 output (default) and 0x80 output | 15:03 |
| strikov-lunch | smoser: this id should be truly unique | 15:03 |
| patdk-wk | why is it not using the wwn from scsi? | 15:04 |
| strikov-lunch | smoser: does scsi_id return any errors with 0x80 or just empty string? | 15:04 |
| strikov-lunch | patdk-wk: is it what scsi_id returns by default (with page 0x83)? | 15:06 |
| strikov-lunch | brb in 15 mins | 15:06 |
| patdk-wk | not sure, don't have access at the moment to scsi disk (all in production, except one machine, but that is in storage powered off) | 15:06 |
| smoser | strikov-lunch, //paste.ubuntu.com/11650647/ | 15:09 |
| smoser | strikov-lunch, http://paste.ubuntu.com/11650647/ | 15:09 |
| smoser | fsking gnome-terminal! | 15:09 |
| patdk-wk | looks like it is 0x83, http://stackoverflow.com/questions/22072039/algorithm-to-get-scsi-id-as-page-0x83 | 15:09 |
| patdk-wk | with one extra info | 15:10 |
| patdk-wk | wwn are uniq per disk, but sata doesn't have wwn's only real scsi disks, unless the hba makes one for sata (depending on firmware, it will or won't) | 15:11 |
| smoser | patdk-wk, thank you. | 15:23 |
| smoser | strikov and i are learning of these things, when first fixing bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371634 | 15:24 |
| smoser | and then hitting bug 1463046 | 15:24 |
| === strikov-lunch is now known as strikov | ||
| strikov | Thanks patdk-wk. We basically trying to detect multipath w/o multipath tool installed. So we initially wanted to do that by looking for two disks with the same scsi_id (0x83). Unfortunately sata disks may have the same scsi_id (0x83) even if they different disks not multipath ones. So I think that we may want to generate id by concatenating scsi_id(0x83) and scsi_id(0x80). | 15:38 |
| patdk-wk | no problem, I haven't done this *much* on linux, but do this a lot on solaris | 15:39 |
| patdk-wk | and on solaris, I stick to just wwn for everything | 15:40 |
| * smoser thinks of some snarky comment wrt solaris, but doesnt find one. | 15:40 | |
| patdk-wk | makes it simple to know what disk failed :) | 15:40 |
| patdk-wk | ya, on linux the best we have is disk-by-id, that I kindof don't like | 15:40 |
| patdk-wk | by path is nice, but also annoying | 15:40 |
| Walex | strikov: SCSI IDs may be a lot longer than that...# | 15:41 |
| Walex | strikov: why not use WWNs | 15:41 |
| Walex | ahhh SATA. Oops. | 15:42 |
| strikov | Walex: how can I get WWN for a scsi disk? Which command line tool does that? | 15:42 |
| Walex | strikov: well, in that stackoverflow page the WWNs are listed too | 15:43 |
| Walex | strikov: but note that when you say "SCSI disk" you are talking of somewhat mythical entities. | 15:43 |
| Walex | strikov: for Linux "SCSI" means "the storage abstraction layer called 'scsi'". Then you have SAS, SATA, FC, ... devices. | 15:44 |
| Walex | if you want to uniquely identify devices that's device-type dependent. | 15:45 |
| strikov | Walex: Yeah, thats a good point. The problem here is that multipath-tools afaik identify multipath by looking for two disks with the same scsi_id. Taking all ^^^ into account I suspect that this is wrong. | 15:46 |
| strikov | Because scsi_id returns some data from the page 0x83 which contains useful info for iscsi disk but contain non-unique info for sata disk. | 15:47 |
| patdk-wk | yep, cause sata lacks wwn | 15:47 |
| patdk-wk | how exactly are people doing multipath over sata? | 15:48 |
| patdk-wk | or is it a mixture of scsi + sata, that is confusing it? | 15:48 |
| strikov | patdk-wk: i don't think they do; the problem is that we can't detect multipath reliably :) | 15:49 |
| strikov | patdk-wk: because sata disks destroy 'two disks with the same scsi_id ==> multipath' logic | 15:49 |
| patdk-wk | looking here | 15:50 |
| patdk-wk | hmm, mine is giving my sata disks wwn's | 15:50 |
| strikov | patdk-wk: another side of this issues is that systems fails to boot with multipath-tools installed if sata disks are available; they return same iscsi_id, multipath try to use them as multipath, everything fails because they are not multipath (just two disks with the same scsi_id) | 15:50 |
| patdk-wk | so not borken, atleast for my workstation :( | 15:50 |
| strikov | patdk-wk: it return something, it's just not unique! | 15:51 |
| patdk-wk | for d in /dev/sd?; do echo "$d:" $(/lib/udev/scsi_id --replace-w hitespace --whitelisted -p 0x83 --device=$d); done | 15:51 |
| patdk-wk | /dev/sda: 350014ee6ad4008e7 | 15:51 |
| patdk-wk | /dev/sdb: 350014ee6ad400df4 | 15:51 |
| patdk-wk | two sata 2.5" laptop disks | 15:51 |
| patdk-wk | ya, it depends heavily on the hba used, and firmware on that hba | 15:51 |
| strikov | patdk-wk: hm, you're lucky :) you can install multipath-tools w/o any issues I think ;) | 15:51 |
| patdk-wk | now, people using lsi hba with IR firmware, should have issues I believe | 15:52 |
| patdk-wk | IT firmware makes uniq wwn's, IR doesn't make wwn | 15:52 |
| patdk-wk | that one above was from just build in intel sata ports | 15:52 |
| patdk-wk | looking to see if I have anything that doesn't behave right for wwn's | 15:53 |
| patdk-wk | ah nice | 15:53 |
| patdk-wk | scsi vm disk has no wwn :) | 15:53 |
| patdk-wk | it's blank | 15:53 |
| patdk-wk | maybe I should multipath it :) | 15:54 |
| patdk-wk | my lsi IT card behaves also | 15:55 |
| strikov | patdk-wk: yeah, so my understanding is that multipath requires some manual setup in general case; you need to know which exact disks are multipath and tell it to the system; auto detection is somewhat problematic | 15:55 |
| patdk-wk | but that is also in a vm | 15:55 |
| patdk-wk | for d in /dev/sd?; do echo "$d:" $(/lib/udev/scsi_id --replace-w hitespace --whitelisted -p 0x83 --device=$d); done | 15:55 |
| patdk-wk | /dev/sda: | 15:55 |
| patdk-wk | /dev/sdb: 350014ee601eaa88b | 15:55 |
| patdk-wk | /dev/sdc: 350014ee05859790a | 15:55 |
| patdk-wk | /dev/sdd: 350014ee3aabd0240 | 15:55 |
| patdk-wk | /dev/sde: 350014ee0ad16a2fe | 15:55 |
| patdk-wk | /dev/sdf: 350014ee2afd87b05 | 15:55 |
| patdk-wk | the vm (root) disk is blank | 15:55 |
| patdk-wk | the passed though lsi card, gives the wwn's | 15:55 |
| patdk-wk | yes, when I used multipath in linux, I always manually configured it | 15:56 |
| patdk-wk | but maybe using a vm will help *fix* the issue? since it seems to have the same problem with empty disks | 15:56 |
| patdk-wk | and could, like if I did the above system, with multipath for the attached disks, could have issues with the vm virtual disks | 15:57 |
| patdk-wk | I imagine that will become a more common setup | 15:57 |
| strikov | patdk-wk: could you run last command with -p 0x80 please? | 15:58 |
| strikov | patdk-wk: i'm trying to convince myself that 0x80+0x83 approach is something useful | 15:58 |
| patdk-wk | for d in /dev/sd?; do echo "$d:" $(/lib/udev/scsi_id --replace-w hitespace --whitelisted -p 0x80 --device=$d); done | 15:59 |
| patdk-wk | /dev/sda: | 15:59 |
| patdk-wk | /dev/sdb: SATA_WDC_WD20EARX-00P_WD-WCAZAD473283 | 15:59 |
| patdk-wk | /dev/sdc: SATA_WDC_WD1502FAEX-0_WD-WMAY04018797 | 15:59 |
| patdk-wk | /dev/sdd: SATA_WDC_WD2002FAEX-0_WD-WMAWP0328862 | 15:59 |
| patdk-wk | /dev/sde: SATA_WDC_WD1501FASS-0_WD-WMAY00241536 | 15:59 |
| patdk-wk | /dev/sdf: SATA_WDC_WD15EARS-00S_WD-WCAVY6072338 | 15:59 |
| strikov | patdk-wk: bah, still no idea for sda | 15:59 |
| strikov | *no id | 15:59 |
| patdk-wk | ya :) | 15:59 |
| patdk-wk | but that is a vmare disk | 15:59 |
| === markthomas|away is now known as markthomas | ||
| patdk-wk | likely if both produce no id, I would ignore that disk totally | 16:03 |
| patdk-wk | nothing you can do | 16:03 |
| solo1 | is there a way to share a folder on a server to download ( option to upload ) files from gdrive ? | 16:15 |
| solo1 | is there a way to share a folder on a server to download ( option to upload ) files from gdrive ? | 16:19 |
| med_ | do any services need to be manually restarted after a tzdata (leapsecond) update? It doesn't seem to do any itself. | 16:53 |
| med_ | do any services need to be manually restarted after a tzdata (leapsecond) update? It doesn't seem to do any itself. | 16:53 |
| med_ | Do any services need a manual kick in the pants (HUP, etc) in order for the tzdata leap second change to be effective. The tzdata upgrade/install doesn't restart any services afaict. | 16:53 |
| hallyn | zul: groan, | 16:54 |
| hallyn | ubuntu@lw1:~/qa-regression-testing/scripts$ virt-install --connect=qemu:///system --wait=0 --force --name qt --ram 64 --disk /home/ubuntu/qa-regression-testing/scripts/libvirt/qatest/qatest.img --import | 16:54 |
| hallyn | Starting install... | 16:55 |
| hallyn | ring any bells? | 16:55 |
| hallyn | ERROR XML error: No PCI buses available | 16:55 |
| zul | hallyn: nope | 16:55 |
| sarnold | med_: I believe all services that do time -> string conversions via the tzdata packages will automatically use the new databases without any effort on your part | 17:19 |
| med_ | sarnold, I got some good feedback from the maintainer of tzdata, infinity, in #ubuntu-motu. Basically, if you are using ntpd (and we are) we don't have anything to do or to worry about. | 17:22 |
| sarnold | med_: though I'll note java has their own time -> string generation things, I haven't got a clue if those auto-recognize updates of their version of their tzdata.. | 17:24 |
| === Wiched is now known as Guest74012 | ||
| hallyn | zul: d'oh! you dropped debian/patches/ubuntu_machine_type.patch | 17:58 |
| zul | oh shit i didnt think i did | 17:58 |
| hallyn | and now i just lost an hour of compile time by doing debian/rules clean in the wrong window | 17:58 |
| hallyn | yeah you rediffed it properly, but left it commented in series :) | 17:58 |
| zul | oops :( | 17:58 |
| zul | hallyn: coreycb should be able to figure this out shouldnt he? ;) | 17:59 |
| hallyn | agreed! | 17:59 |
| hallyn | zul: that patch probably ought to be sent upstream, ther'es no reason for delta there | 18:08 |
| hallyn | and btw while i lost a lot of time to this, i should have started by looking at the debdiff and i'd have noticed it - myown fault :( | 18:08 |
| zul | sorry about this | 18:09 |
| hallyn | no i shoulda noticed. anyway should have coreycb send that patch upstream? :) | 18:10 |
| coreycb | hallyn, I'm sure zul can handle it | 18:11 |
| === Lcawte is now known as Lcawte|Away | ||
| hallyn | hrmph, still a lot of failures. | 18:57 |
| === voidptr is now known as voidstar | ||
| === esde_ is now known as esde | ||
| === athairus is now known as afkthairus | ||
| === Lcawte|Away is now known as Lcawte | ||
| === Lcawte is now known as Lcawte|Away | ||
| === Lcawte|Away is now known as Lcawte | ||
| teward | stupid totally not insane question: is it possible to get OpenSSL 1.0.2 and OpenSSL included with 14.04 working together? | 21:53 |
| teward | such that I have 1.0.2 executable via openssl_1.0.2 or similar | 21:54 |
| teward | it's needed for a CLI script I use to test SSL settings, hence why I need both, one for Ubuntu normal stuff to use, and one for the script to use :/ | 21:55 |
| cryptodan | teward: you can compile one and place it in /usr/local/sbin | 21:56 |
| teward | cryptodan: mmm, know what deps I might need for that? | 21:56 |
| cryptodan | teward: not sure | 21:56 |
| teward | i'll go hunting, starting with the openssl build deps we already have, then | 21:57 |
| teward | thanks | 21:57 |
| cryptodan | welcome that way those in /usr/local/sbin remain untouched | 22:01 |
| === hggdh_ is now known as hggdh | ||
| === zz_DenBeiren is now known as DenBeiren | ||
| TheEagerPadawan | hi does anybody know where i could find some good videotutorials relating to linux server configuration (like DNS, DHCP, Web servers, FTP, Samba, NFS etc ...) | 23:13 |
| teward | TheEagerPadawan: unfortunately not, each of them has their own quirks and hellish configuration problems | 23:20 |
| teward | TheEagerPadawan: and are totally different from eac other | 23:20 |
| TheEagerPadawan | well i do know there is a diffrence between ubuntu and centos, starting from the package manager alone, and file setup | 23:21 |
| teward | TheEagerPadawan: i mean service to service | 23:21 |
| teward | not OS to OS | 23:21 |
| TheEagerPadawan | oh :) | 23:21 |
| TheEagerPadawan | my bad | 23:21 |
| sarnold | TheEagerPadawan: the serverguide in the /topic is the best intro-level resource I can think of; I can't say I've seen videos, but I've never gone looking | 23:21 |
| teward | ^ that | 23:21 |
| teward | i agree with sarnold | 23:21 |
| teward | start with the server guide | 23:21 |
| teward | and ask questions here if you get stuck (we'll try and help you probably) | 23:22 |
| sarnold | these things are just complicated enough that it doesn't lend itself well to a linear video presentation: there's dozens or hundreds of choices to make for each service based on what you're trying to accomplish | 23:23 |
| teward | sarnold: stupid question, but would replacing 14.04 LTS OpenSSL 1.0.1 with 1.0.2 from upstream break any core functions that you're aware of? Putting it on a server because it's going to run scheduled SSL checks with a given tool that needs 1.0.2 for bit strength checks for ciphers andsuch | 23:23 |
| teward | also agree with sarnold there | 23:23 |
| teward | (dedicated to this server, that is) | 23:23 |
| sarnold | teward: yikes, uh... that's definitely a "you get to keep both pieces" situtation. I'd compile from source, stick it in /usr/local/. and compile whatever tools you need against that version. | 23:24 |
| teward | sarnold: the tool uses openssl binaries for all the checks, and has fun with the output (the tool is a bash script xD). i was planning a from-source compile anyways, Debian only has 1.0.2a | 23:24 |
| teward | this is a very specialized use case I know but... :P | 23:25 |
| sarnold | teward: it has somewhat bothered me that we've neutered our packages for forensics use, forcing someone to maintain their own copy if they're writing tools, but honestly, keeping up with the security issues in these crypto toolkits is bad enough that having purpose-written tools is probably for the best | 23:25 |
| teward | sarnold: was also going to see if I could get the thing to compile the binary as openssl_1.0.2 so i don't break existing functions but meh | 23:25 |
| teward | sarnold: agreed. | 23:25 |
| teward | sarnold: before i went and started stabbing the openssl source tarball to try and build openssl as openssl_1.0.2 i wanted to see if using 1.0.2 instead of 1.0.1 would nuke anything core, my guess is "Yes, it will" | 23:25 |
| teward | judging by your statement | 23:26 |
| sarnold | teward: you might get away with doing some namespace hackery, create a new private filesystem namespare with unshare, mount -o bind the binaries and libraries you need.. | 23:26 |
| teward | mmm | 23:26 |
| teward | yeah, perhaps, i'll give it some thought :P | 23:26 |
| sarnold | teward: I think the openssl team -tries- to maintain ABI, but .. keeping the abi within an upstream release is a lot more likely than across upstream releases. | 23:27 |
| teward | sarnold: BTW, next not as stupid question, I assume 1.0.2a in Wily is patched up for any bugs between a and b? | 23:27 |
| teward | or rather, security bugs | 23:27 |
| teward | :P | 23:27 |
| teward | you would probably have a better insight on that answer than me after all :P | 23:27 |
| sarnold | teward: everything I know is here: http://people.canonical.com/~ubuntu-security/cve/pkg/openssl.html :) | 23:28 |
| teward | sarnold: might want mdeslaur to double check the upstream link on 2015-1791 that isn't the 1.0.1 one... getting 400s from upstream git tracker there | 23:29 |
| sarnold | (and that lone CVE I very nearly marked 'low' last week; multithreaded ssl servers just seemed like a strange strange thing, but I decided 'medium' since it -is- openssl after all..) | 23:29 |
| teward | sarnold: oh so you set that one there, good, you can check the upstream links :P | 23:30 |
| sarnold | teward: openssl git is _funky_, half the time I get ABE errors from noscript | 23:30 |
| teward | lol | 23:30 |
| sarnold | at least noscript lets you resubmit the requests unsafely, and that usually works | 23:30 |
| teward | sarnold: well, "400 - Invalid hash parameter" from their system sounds different :P | 23:30 |
| teward | o wait that's the 1.0.1 one | 23:30 |
| teward | nevermind | 23:30 |
| * teward bashes head against screen | 23:30 | |
| teward | sarnold: cve breakage on the second upstream link - the space and the 1.0.1 break the link | 23:31 |
| teward | otherwise it works | 23:31 |
| sarnold | heh so it does | 23:31 |
| sarnold | we use that (..) notation everywhere; it might be worth fixing our html-generator some day | 23:31 |
| teward | sarnold: probably :0 | 23:31 |
| teward | sarnold: probably :P | 23:31 |
| teward | sarnold: or maybe add a comment to the bug, such that "This link works, the one below for 1.0.1 doesn't - linkhere" | 23:32 |
| teward | :P | 23:32 |
| teward | but that's your guys stuff | 23:32 |
| teward | :p | 23:32 |
| * teward is mostly hands off :P | 23:32 | |
| teward | except where it comes to nginx usually :) | 23:32 |
| === Lcawte is now known as Lcawte|Away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!