Re: [arch-general] package contents on fresh Arch install, like python etc...
On 21/06/2019 19:45, Eli Schwartz via arch-general wrote: > On 6/21/19 12:13 PM, Jude DaShiell wrote: >> Also, man which >> If you get a chance the linux cookbook will be informative reading given >> your new position. > Please do *not* use /usr/bin/which, especially not if you write scripts. > It is non-POSIX, not portable between different different systems if you > write scripts, and even on an interactive console where you know you > personally have the "which" package installed, the results are more > confusing and less useful than using the native shell introspection. > > use `command -v` to find where a command exists, or, in bash, `type -a` > if you want to see all possible options. > > For more details, see: > https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250 > Especially note the "Status today" paragraphs, and if you stubbornly > wish to continue using "which" despite its well-known pitfalls, then > carefully avoid any systems where "which" is implemented as a csh script > (like many commercial Unix systems today). > > ... > > Use the "conflict" command if you're afraid you may have multiple > versions of an externally available executable file in your $PATH and > you want to check where they are and what you're actually using. > > Since the common use case of "which" is when you actually want to know > whether you're using the wrong version of something, the ideal > interactive debugging tool is "type -a"... but the "conflict" command > can do one better -- limited to executables and not shell builtins, > aliases, or functions -- and list *all* conflicting command binaries. > Should you always create POSIX-compatible scripts though? All these non-POSIX tools were created to ease your job, and you blow them away as non-POSIX? If you're creating a single-purpose local script, I think it's fair to make it a bash script and use tools which you have available on your install, instead of limiting yourself to frankly ridiculous workarounds to the shortcomings of POSIX. Just because a tool can do anything doesn't mean it can do everything well, or that you have enough cognitive capacity at 3 am to write your stupid POSIX-compatible shell scripts. P.S. which is an absolutely terrible command though, modern POSIX alternatives are much better for this specific use case. -- Regards, Juha Kankare
Re: [arch-general] package contents on fresh Arch install, like python etc...
On 6/21/19 12:13 PM, Jude DaShiell wrote: > Also, man which > If you get a chance the linux cookbook will be informative reading given > your new position. Please do *not* use /usr/bin/which, especially not if you write scripts. It is non-POSIX, not portable between different different systems if you write scripts, and even on an interactive console where you know you personally have the "which" package installed, the results are more confusing and less useful than using the native shell introspection. use `command -v` to find where a command exists, or, in bash, `type -a` if you want to see all possible options. For more details, see: https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250 Especially note the "Status today" paragraphs, and if you stubbornly wish to continue using "which" despite its well-known pitfalls, then carefully avoid any systems where "which" is implemented as a csh script (like many commercial Unix systems today). ... Use the "conflict" command if you're afraid you may have multiple versions of an externally available executable file in your $PATH and you want to check where they are and what you're actually using. Since the common use case of "which" is when you actually want to know whether you're using the wrong version of something, the ideal interactive debugging tool is "type -a"... but the "conflict" command can do one better -- limited to executables and not shell builtins, aliases, or functions -- and list *all* conflicting command binaries. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] package contents on fresh Arch install, like python etc...
On Fri, 21 Jun 2019, mpan wrote: > Date: Fri, 21 Jun 2019 00:38:12 > From: mpan > Reply-To: General Discussion about Arch Linux > To: arch-general@archlinux.org > Subject: Re: [arch-general] package contents on fresh Arch install, > like python etc... > > > A day back, i made a fresh install of Arch on my desktop. It is completely > > fresh as like it doesnt even have an account other than root. > > My doubt is, wont basic tools like python come in Arch install? or do we > > have to install by ourselves? > You are the administrator. You are choosing what you want to be > installed. The base group contains only the basic tools and their > dependencies. > > > also can anyone give me a brief approximate list of packages that will come > > pre-installed in Arch, other than gnu tools? > pacman -Sg base > > Also, man which If you get a chance the linux cookbook will be informative reading given your new position. --
Re: [arch-general] CVE-2019-11477 (/proc/sys/net/ipv4/tcp_sack)
On 6/21/19 8:25 AM, David C. Rankin wrote: > After 5.12.1 is there any further mitigation needed for: > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11477 > > related: > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11478 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11479 > > Suggested work-around: > > echo 0 > /proc/sys/net/ipv4/tcp_sack > > or > > iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP > > Are either needed after latest kernel, or is this resolved? > I guess you mean 5.1.12 as long as you are not a visitor from the future. 5.1.11 was the upstream fix version for the SACK issues, you can use our Arch Linux specific security tracker to get this information: https://security.archlinux.org/CVE-2019-11477 https://security.archlinux.org/CVE-2019-11478 https://security.archlinux.org/CVE-2019-11479 which lists all affected and fixed variants/versions. there have been advisories published on the tracker and via our sec announcements ML. So as long as you are running latest kernels, no other mitigation is needed. cheers, Levente signature.asc Description: OpenPGP digital signature
[arch-general] CVE-2019-11477 (/proc/sys/net/ipv4/tcp_sack)
After 5.12.1 is there any further mitigation needed for: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11477 related: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11478 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11479 Suggested work-around: echo 0 > /proc/sys/net/ipv4/tcp_sack or iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP Are either needed after latest kernel, or is this resolved? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] package contents on fresh Arch install, like python etc...
Wow.. thank u guys for explanation and for command "pacman -Sg base" .. now i understood.. On Fri, 21 Jun 2019, 10:14 am Eli Schwartz, wrote: > On June 21, 2019 12:05:23 AM EDT, Ram Kumar via arch-general < > arch-general@archlinux.org> wrote: > > Dear Archers, > > A day back, i made a fresh install of Arch on my desktop. It is > > completely > > fresh as like it doesnt even have an account other than root. > > My doubt is, wont basic tools like python come in Arch install? or do > > we > > have to install by ourselves? > > > > also can anyone give me a brief approximate list of packages that will > > come > > pre-installed in Arch, other than gnu tools? > > > > Thanks in advance > > yours fellow newbie Archer > > Ramkumar > > That's not really how it works. Arch does not come with programs > preinstalled, because when you follow the Installation Guide and `pacstrap` > a new system, you interactively choose which programs from the base group > are desired. > > What will be installed is: > - A kernel, because you need it to boot. > - Pacman, because it is used for installing and removing things. > - Standard POSIX tools (*not* gnu tools) like the core utilities, > grep, awk, sed, tar, find, sh and so on. Note that most are the > GNU versions by default, but it is possible to swap them out, e.g. > use busybox. > - Select tools that are used by people for basic setup, like > filesystem support tools or networking tools (wpa_supplicant, > netctl). > > Python, and anything else you want on an application level, should be > generally assumed to not exist unless you install it manually or unless it > is basic scripting tools that are advertised by POSIX (in which case you > can usually use them on any Linux distro without checking whether they are > installed). > > -- > Eli Schwartz > Bug Wrangler and Trusted User
