| * genii notes no leading slash before home | 00:00 | |
| truelai | rsync -az "backups\/daily.0\/MTL_fileSrv\/home\/Users\/amasse\/AM Desktop\/Apex.*" "root@10.1.1.74:/home/Users/amasse/AM Desktop" | 00:01 |
|---|---|---|
| truelai | rsync: change_dir "/backups/daily.0/MTL_fileSrv//backups\/daily.0\/MTL_fileSrv\/home\/Users\/amasse\/AM Desktop\" failed: No such file or directory (2) | 00:01 |
| truelai | doesn't matter | 00:02 |
| sarnold | truelai: start with this: ls -l /backups/daily.0/MTL_fileSrv//backups\/daily.0\/MTL_fileSrv\/home\/Users\/amasse\/AM Desktop\ | 01:00 |
| sarnold | truelai: it'll probably fail | 01:00 |
| sarnold | truelai: start removing directory components from the end until you find where it succeeds | 01:00 |
| truelai | Thanks sarnold | 01:00 |
| truelai | having a new issue now | 01:00 |
| truelai | I want to prefix every line of a file with the following: | 01:00 |
| truelai | rsync -az -e "ssh -i /root/.ssh/id_ed25519" -s | 01:01 |
| truelai | Any ideas? | 01:01 |
| truelai | I'm failing with both awk and sed | 01:01 |
| sarnold | awk '{print "hello " $_; }' /etc/passwd | 01:03 |
| sarnold | worked for me on a *simple* input file | 01:03 |
| truelai | awk '{print "rsync -az -e "ssh -i /root/.ssh/id_ed25519" -s" $_; }' encrypted-files-full-path-escaped.txt out.txt | 01:05 |
| truelai | awk: cmd. line:1: {print "rsync -az -e "ssh -i /root/.ssh/id_ed25519" -s" $_; } | 01:05 |
| truelai | awk: cmd. line:1: ^ syntax error | 01:05 |
| sarnold | need more \ :) | 01:05 |
| truelai | for the period? | 01:06 |
| sarnold | the "ssh | 01:06 |
| truelai | can you show me the line? | 01:06 |
| truelai | awk '{print "rsync -az -e "ssh -i /root/\.ssh/id_ed25519" -s" $_; }' encrypted-files-full-path-escaped.txt out.txt | 01:06 |
| truelai | this does not work | 01:06 |
| sarnold | try: awk '{print "rsync -az -e \"ssh -i /root/.ssh/id_ed25519\" -s" $_; }' encrypted-files-full-path-escaped.txt | 01:08 |
| sarnold | I'm guessing you wanted the out.txt to contain this output -- if so, use > out.txt at the end | 01:08 |
| truelai | oh snap!!! | 01:08 |
| truelai | :-* | 01:08 |
| truelai | Thanks much, man! | 01:08 |
| sarnold | sed -ifoo is also awesome | 01:09 |
| truelai | so are you | 01:09 |
| sarnold | that does an in-place edit on the file, creating a backup file with 'foo' | 01:09 |
| sarnold | <3 :) thanks | 01:09 |
| sarnold | I almost always use sed -i without a backup, but that's a bit dangerous unless it's something you *can't* mistype :) | 01:09 |
| rbasak | teward: on bug 1743592 | 01:35 |
| ubottu | bug 1743592 in nginx (Debian) "NGINX fails to start/install/upgrade if IPv6 is completely disabled." [Unknown,New] https://launchpad.net/bugs/1743592 | 01:35 |
| rbasak | I wasn't paying close attention, but I'm really surprised that you disabled IPv6 support by default in nginx in Focal. That does seem like a regression to me. | 01:35 |
| rbasak | slashd: ^ | 01:36 |
| rbasak | IMHO, the default should be to focus on working on a default installation which would have IPv6 enabled. | 01:36 |
| rbasak | The real fix would be for nginx to support listening properly on all interfaces on port 80 whether they are 4 or 6 and regardless of whether one is disabled. | 01:37 |
| rbasak | My SRU opinion was just "don't change stable release behaviour". Sorry I didn't write up any suggestions for development release behaviour change at the time (AFAICT - I'm not contradicting myself, am I?) | 01:39 |
| teward | rbasak: we can revert that easy but the discussion was with others to disable it because that's what upstream has - feel free to revert that, or I will tomorrow | 02:56 |
| teward | this being said... that doesnt solve the ipv6 missing problem | 02:56 |
| teward | I was intending to revert it after thinking on it this evening | 02:57 |
| teward | I'll revert in the morning. You want to summarize that we agreed collectively to not cater to v6-disabled cases? | 02:57 |
| teward | (I'm a little busy...) | 02:58 |
| rbasak | teward: I asked some colleagues their opinion. I appreciate you being so responsive, but let's make sure everyone is agreed to avoid reverting a revert :) | 03:22 |
| rbasak | Sure, I'm happy to summarize following discussion | 03:23 |
| rbasak | (also I'm technically out until Monday) | 03:23 |
| teward | rbasak: i think this was because there are some specialized deployments that disable v6 but... thats going to be a larger discussion. Comment on the bug as well and indicate we are discussing more internally before a revert. Todays been s*** to a high degree so I’m trying to NOT deal with stress at the moment | 03:51 |
| teward | Or rather, avoid some stress | 03:51 |
| lordievader | Good morning | 07:30 |
| ruben23 | hi there guys anyone can help | 08:55 |
| ruben23 | i got myself lockout on my ubuntu server i login as user ruben23 but when i do sudo it ask for password even i did not set any, problem i disable root access | 08:57 |
| lordievader | ruben23: What are you trying to do exactly? | 09:00 |
| ruben23 | lordievader: i got user ruben23 then i disable root login on my ssh server and this user i did not set a password, problem i cant do sudo with my user coz it ask for password | 09:01 |
| lordievader | How did you disable the root login? | 09:02 |
| lordievader | Were you able to use sudo before? | 09:02 |
| ruben23 | so im pretty lockout.? i cant do anything.? i disable it on sshd_config ( permit root login - no | 09:02 |
| ruben23 | lordievader: this is my first reboot to try it after setting up, problem its asking for password even i did not set | 09:03 |
| lordievader | You never used sudo before? It asks for your user's password. | 09:04 |
| ruben23 | lordievader: yes | 09:05 |
| lordievader | ruben23: Does it work with your user password? | 09:08 |
| ruben23 | lordievader: its working now, thanks a lot | 09:15 |
| === Wryhder is now known as Lucas_Gray | ||
| === V7 is now known as nopm | ||
| === nopm is now known as [88] | ||
| === [88] is now known as |88| | ||
| === |88| is now known as V7 | ||
| weedmic | How likely is plugging in a pci-e bluetooth card going to work? my kids what to get bluetooth headsets for the living room | 16:07 |
| weedmic | is this something easy, or a pandora's box? | 16:07 |
| pragmaticenigma | Is this on a desktop or server? | 16:07 |
| weedmic | it is ubuntu 18.04 running on a dual linux 4u convertible (tower). | 16:08 |
| pragmaticenigma | Other than bluetooth doesn't transmit well through walls... I'm not sure how robust the support is for the various chipsets on the market. | 16:09 |
| weedmic | if it's going to be a bother, is there a brand I should try to find - perhaps intel? | 16:09 |
| weedmic | ok, the only wall would be the case ?wrapper? as it is visible/open to air | 16:09 |
| weedmic | i guess it doesn't matter, i see the price is very very cheap - less than a snack/lunch - ty tho | 16:10 |
| pragmaticenigma | cheep may mean less support... but cheep means can't hurt to try | 16:11 |
| pragmaticenigma | just make sure it has an external antenna | 16:11 |
| weedmic | :D support - i've not had support since 1995 - i mention linux and they hang up | 16:11 |
| weedmic | good - i did not see an antenna in the advert - this is for bluetooth (not wifi). looking at others | 16:12 |
| pragmaticenigma | well, I was referring to kernel supporting the chipset... but I think you knew that | 16:12 |
| pragmaticenigma | bluetooth through a metal case is going to be iffy... better if the card has at least some sort of co-axil port to hook an external antenna to. I'm not sure if all cards would come with the external antenna with the unit | 16:13 |
| weedmic | o oic, kernel support - still looking for one with antenna | 16:13 |
| pragmaticenigma | weedmic: I'd look for a "port" on the card, that lets you attach an antenna... Might be easier to find, and the card documentation should tell you what type of antenna connector and specs are supported | 16:18 |
| weedmic | ty | 16:22 |
| teward | rbasak: can you review the latest items? Because I think trying to handle 'all cases' with customising postinst, etc. is a catch 22 | 16:37 |
| teward | as is just going back to having v6 support out of the box | 16:37 |
| teward | need a second opinion | 16:37 |
| teward | preferably with a Canonical opinion/twist to it | 16:37 |
| sdeziel | teward: to add to possible solutions, using "listen [::]:80 default_server ipv6only=off;" alone seems to do the right thing no matter what is present, v4 only, v6 only or both | 16:43 |
| teward | sdeziel: i think we're still on a double edged sword. Because if v6 is completely disabled I don't think that'll work | 16:44 |
| teward | that's the reason for the original 'bug' being filed | 16:44 |
| sdeziel | teward: maybe not a perfect test but I nuked all v6 on my test container and it worked | 16:44 |
| teward | i'm tempted to drop that delta from Debian and then go back to the original Listen lines and argue that the lack of v6 in a configuration is a nonstandard edge case that the 'defaults' cannot necessarily adapt to | 16:44 |
| teward | sdeziel: propose it on the bug then? | 16:45 |
| teward | the problem I see is | 16:45 |
| teward | if we keep catering things to these edge cases | 16:45 |
| teward | we're going to have such insane complexity it's not going to be a good thing | 16:45 |
| sdeziel | teward: yes, I'll add this to the bug | 16:45 |
| sdeziel | teward: I think that probing for available inet family is crazy ;) | 16:46 |
| sdeziel | I don't want dynamic variable configs ;) | 16:46 |
| rbasak | I know that there's a way in general on Linux for a single socket bind to listen on both and just dtrt. | 17:05 |
| rbasak | Maybe sdeziel's suggestion is exactly that. | 17:05 |
| sdeziel | it's what I'm trying to find, now trying other variations | 17:05 |
| teward | to be fair | 18:04 |
| teward | i'm OK with it displaying IPv6 addresses in there | 18:04 |
| teward | for logs | 18:04 |
| teward | as long as it has the addresses. But that brings into question a larger question: do we really want v4 to show up as v6 translated in the logs? | 18:04 |
| teward | by default | 18:04 |
| teward | because that's what the change sdeziel proposed would make. | 18:05 |
| sdeziel | teward: yeah, I'm not too keen on having IPv4-mapped IPv6 (with the "::ffff:" prefix) but I never use the default vhost myself so I don't really care | 18:22 |
| teward | if the choice is between "Support no-v6 and no-v4 systems" and "ipv6 mapped v4" i'll choose the second, but the default fallback is "You guys are using non-standard configurations so just write your own configuration and deploy that" | 18:24 |
| teward | which would revert the changes I did to remove the v6 components and drop a delta | 18:24 |
| teward | given that FF comes up next week, I'd like to make a decision sooner than later, rbasak and sdeziel | 18:35 |
| teward | thoughts? | 18:35 |
| rbasak | teward: I think we should revert, but I think what to replace it with is perhaps still under discussion? | 18:46 |
| sdeziel | agreed on both counts | 18:46 |
| rbasak | But I think revert-and-do-nothing-else is still a better option than the current situation. | 18:46 |
| teward | i think leaving it without a replacement is satisfactory | 18:46 |
| teward | since not having ipv4 or not having ipv6 is not a 'normal' configuration | 18:46 |
| rbasak | I agree - the only question is if we can do any better | 18:47 |
| teward | at least, not what we would consider 'normal' for typical behavior of a system | 18:47 |
| teward | rbasak: I can think of a dozen things we can check - but that makes the complexity increase substantially | 18:47 |
| teward | this close to FF I don't want to introduce breakage, so I'm more inclined to revert and leave it alone, and then deal with *that* come 20.10 cycle | 18:47 |
| sdeziel | teward: having too clever postinst is dangerous IMHO | 18:47 |
| rbasak | What I'd like is a simple nginx configuration that will always listen on all available addresses on both 4 and 6 as available. | 18:47 |
| teward | sdeziel: *points at last statement* | 18:47 |
| teward | rbasak: that's only available if we use sdeziel's approach | 18:47 |
| rbasak | If that's not possible, we should file an upstream bug requesting that as a feature. | 18:47 |
| teward | there's no 'dynamic' listening that way | 18:48 |
| rbasak | And I'd be happy to leave it at that. | 18:48 |
| teward | well for the time being | 18:48 |
| rbasak | "listen [::]:80 | 18:48 |
| rbasak | default_server ipv6only=off;" | 18:48 |
| rbasak | ^ that approach? | 18:48 |
| teward | yes, but that makes the logs all log IPv6 addresses ::ffff:10.1.2.3 as an example | 18:48 |
| teward | which adds a *different* problem into the mix | 18:49 |
| teward | logs no longer match expected format | 18:49 |
| teward | s | 18:49 |
| teward | DAMN YOU LAGGY INTERNET *throws a wrench at the work internet* | 18:49 |
| rbasak | That's not good either - especially as users would likely only find out too late. | 18:49 |
| rbasak | So in that case, I think revert and do nothing further for now is the best option. | 18:49 |
| teward | i agree | 18:49 |
| rbasak | And ask nginx to fix upstream, assuming that's possible with a listen on [::]. | 18:49 |
| rbasak | (surely it is?) | 18:50 |
| teward | rbasak: you'd have to ask them :p | 18:50 |
| rbasak | Oh, I just saw the bug comment | 18:50 |
| sdeziel | the "::ffff:" can be confusing users and log parsers (those should be fixed though) | 18:51 |
| teward | rbasak: sdeziel: changes are revered in 1.17.8-0ubuntu2 which i'm uploading now | 18:57 |
| teward | i left the bug as 'Opinion' as we can discuss later. | 18:57 |
| sdeziel | sounds good to me, thanks teward | 18:58 |
| teward | (Opinion's what I use when the issue remains under discussion but no real solution has come from it yet to 'fix' the issue, or if it even is an issue) | 18:58 |
| rbasak | teward: thanks! | 18:58 |
| rbasak | teward: I think the bug is valid, but Wishlist. Perhaps no action without upstream support. But by default we should listen on both 4 and 6 as available, not fail if one is disabled, and log properly. | 18:59 |
| sarnold | I haven't been following closely but that sounds like a good outcome to me | 19:00 |
| rbasak | I think that's a reasonable position so Triaged is fine - awaiting someone to implement that upstream as required, or find some other acceptable solution. | 19:00 |
| teward | rbasak: i don't disagree (If you want to set it as Wishlist you can, but right now the requested functionality doesn't track with the goal for this cycle which is why I chose Opinion. That said, I've got my own headaches with migrating mail between IP ranges right now, so I can't send that email at the moment to the mailing lists - any chance you can email in to nginx-devel@nginx.org for that discussion? | 19:01 |
| teward | since moving IP ranges also means complete mail system reconfiguratiosn >.< | 19:01 |
| sdeziel | In my opinion, upstream already supports what you described rbasak. I think that ipv4-mapped IPv6 should be considered valid to put in logs, even if it may be confusing to some | 19:01 |
| teward | i don't disagree with sdeziel | 19:01 |
| teward | but lets make that logging change a 20.10 'target'. | 19:01 |
| teward | rather than for 20.04 | 19:01 |
| teward | this close to FF I don't want to break logging parsing | 19:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!