Re: [arch-general] No login after update
On 8/19/20 15:02, Manuel Reimer wrote: > Hello, > > I know that Arch is not for the "average user" and some background > knowledge is expected, but this was the first time I needed a boot stick > since I think at least one year. > > Some minutes ago I did a regular system update and after that decided to > reboot. After reboot I was unable to log into my system. After fiddling > a bit I rebooted to an Arch boot stick to find the following message in > pacman.log: > > [2020-08-19T20:42:55+0200] [ALPM] warning: /etc/pam.d/system-login > installed as > /etc/pam.d/system-login.pacnew > > As this seemed to be a candidate that may cause login problems, I > deleted "system-login" and moved the ".pacnew" into place. > > After reboot I'm now able to log in again... > > IMHO something like this should not happen... > > Maybe it's worth a note on the Arch homepage that it is important to > move this pacnew into place before reboot? > > Manuel I'm just going to reiterate some things, and offer a solution that would have saved you this headache, and then I'm ignoring this thread as it's tiresome. 1.) .pacnew files shouldn't be ignored. They are only created if *you* (or a mispackaged software) have modified files provided by a package from their default state. 2.) True of anything, really, but don't modify PAM files unless you have a significant understanding to a complete grok of what you're doing. 3.) This isn't a news item, as it's isolated to your particular install and customizations. As for the solution, https://aur.archlinux.org/packages/etc-update/ Ta-da. There are other packages that do similar things. You could even have it run automatically after certain packages update with a hook[0]. By running that after your -Sy and before the reboot, you'd see that the line present in your configuration is not part of the default managed by pacman/the package, with the option to: - remove it (effectively reverting to the default file as provided by the package) - merge it with the new one - interactively edit etc. It even cleans up .pacnew files for you after you've made your decisions. You now have no excuse to have .pacnew files all over nor to have changes that are incompatible with new software (provided you read the software's release notes to see if the deprecated, renamed, etc. a configuration in the new version). [0] https://jlk.fjfi.cvut.cz/arch/manpages/man/alpm-hooks.5 -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Question about packaging a library (AUR)
On 7/21/20 12:46 PM, Eli Schwartz via arch-general wrote: > > Dominik, > > $ pkg-config gstreamer-1.0 --variable=pluginsdir > > It's not an option to provide the library in /usr/bin, but a usable > workaround would be to symlink the binary in /usr/bin but install it in > /opt/transcribe/. Check to see if it correctly picks up the right > location, though. ;) You might need to create a wrapper script instead, > which invokes it without a symlink. > > > You may wish to clarify with upstream if it can use the more customary > location. > This is how I would (and do, for one or two packages I maintain) do it. Note that this was essentially the primary purpose of /opt[0][1]. A symlink may or may not work. If it does not, a wrapper that calls the binary and pass along arguments specified at invocation would work fine. e.g. something like: #!/bin/bash # 3/4 times if this works, a symlink in /usr/bin/ works. /opt/transcribe/transcribe "$@" # OR, if it relies heavily on relative paths, it's safer to do: #cd /opt/transcribe #./transcribe "$@" [0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Why bind-tools was merged into bind package?
Responses inline. On 7/20/20 03:15, Óscar García Amor via arch-general wrote: (SNIP) > > The problem is. Where is the limit? The whole distribution in one > package? The argument is the same, if you don't need it simply don't > use it. Because the binaries formerly known as "bind-tools" are a part of BIND9 proper[0]. Upstream, by including "bind-tools" binaries in the source for the BIND9 daemon, ipso facto *intends* them to be built (and thusly packaged) together. To do so otherwise is - one can make the argument - *not* The Arch Way[1]. Sure, split packages are a thing, but they can get messy and are a bit more of a pain to maintain. Simplicity, being a core value of Arch, prefers monolithic packages where reasonable and sensible. I think this is plenty sensible. There are more tools to investigate DNS than host, dig, nslookup. What you probably want is ldns[2] for your specific use cases. Alternatively, you can write your own tools -i.e. [3a][3b]) that do and behave *exactly* as you want them to, with no extra frills which leaves your install even more minimal than bind-tools would have. You can also, of course, modify the PKGBUILD[4a] for bind yourself, use it to build a split package, and then even add it to your own repository[4b] if you feel that keeping them separate packages is superior. You have a lot of options to make your system behave exactly how *you* want it to without requesting Arch to change *its* design decisions. > In this case we are talking about binaries widely used that will be > installed with a service rarely used. I think that packages that have > enough entity to be splitted should do it. From my point of view is > safer don't have a service installed than installed an disabled. > > Greetings. > See again the Arch Way[5]. Arch promises simplicity; it does not promise appeal to masses. Exploiting a service that is installed but not running (as unlike many other distros, Arch does not automatically enable/start a service upon installation) requires access to the machine in the first place. A vulnerability in bind's daemon, at that point, is going to be much less a concern than the attacker actually having arbitrary execution privileges on your box at that point in time, I'd reckon. [0] https://gitlab.isc.org/isc-projects/bind9 [1] https://wiki.archlinux.org/index.php/Arch_Linux#Simplicity [2] https://www.archlinux.org/packages/core/x86_64/ldns/ [3a] https://www.dnspython.org/ [3b] https://www.archlinux.org/packages/community/any/python-dnspython/ [4a] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/bind [4b] https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Custom_local_repository [5] https://wiki.archlinux.org/index.php/Arch_Linux#User_centrality -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as default shell?
On 6/17/20 15:58, brent s. wrote: > This is false. Or at the least, grievously inaccurate. To clarify: This is less-so aimed at OP; the only issue there was a poor choice of words and explaining the suggested switch. The previous post was aimed moreso at those that do not understand there are two shells: one the system uses in scripts (usually init scripts, but more on that in a moment) vs. one the user uses, the interactive shell (the one you run commands from). /bin/sh should be fully POSIX-compatible, /bin/bash has extra features that users would find useful (such as various completion functions, etc.) dash is written to be POSIX-compliant, but no more. Now, to init- because Arch uses systemd (and, yes, now Debian and Ubuntu), one must wonder what benefit, if any, this actually serves. systemd invokes the command directly, it does not spawn a shell to run an init script like sysvinit, upstart, openrc, etc. This is, primarily, the purpose of the system shell. I don't really see much of a benefit to it being that Arch uses systemd. Granted, it probably wouldn't harm much either given the purpose of the system shell, and probably why those who have already changed it haven't seen any noticeable effects. It just seems like an unnecessary change. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as default shell?
On 6/17/20 14:18, Piscium via arch-general wrote: (SNIP) > ... A possible issue is bashisms, however Ubuntu has > been using dash as default for 14 years and Debian also for several > years so hopefully most scripts have had bashisms removed by > upstreams. This is false. Or at the least, grievously inaccurate. Both Ubuntu and Debian use dash as the symlinked shell for /bin/sh, the default *system shell*, NOT the interactive shell for users.[0][1] Both continue to use bash as the default shell for the interactive shell (user shell). Install the latest Ubuntu and/or Debian in a VM if you don't believe me, but you'll see the same: root@ubuntutest:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04 LTS Release:20.04 Codename: focal root@ubuntutest:~# which $SHELL /bin/bash root@ubuntutest:~# ls -l $SHELL -rwxr-xr-x 1 root root 1183448 Feb 25 12:03 /bin/bash root@ubuntutest:~# file $SHELL /bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a43fec47192ff49c2d3fed671f2be8df7e83784a, for GNU/Linux 3.2.0, stripped root@ubuntutest:~# echo $SHELL /bin/bash root@debian:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 10 (buster) Release:10 Codename: buster root@debian:~# which $SHELL /bin/bash root@debian:~# ls -l $SHELL -rwxr-xr-x 1 root root 1168776 Apr 18 2019 /bin/bash root@debian:~# file $SHELL /bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=ffe165dc81a64aea2b05beda07aeda8ad71f1e7c, stripped root@debian:~# echo $SHELL /bin/bash In fact, Debian explicitly warns that dash is intended to NOT be used as the interactive shell: "It is not intended to be used interactively by a user, for example, in a terminal emulator, but rather focuses on speed and compatibility with standards. Therefore, many interactive features are not present in Dash, making it faster and more memory efficient than Bash."[1] It's faster *because they removed user features*. [0] https://wiki.ubuntu.com/DashAsBinSh [1] https://wiki.debian.org/Shell#Non-interactive_Shell -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] How will Arch handle systemd 245 and homed?
On 5/7/20 22:54, David C. Rankin wrote:
> All,
>
> I just read the article about the major change coming to systemd 245 at:
>
> https://www.techrepublic.com/article/linux-home-directory-management-is-about-to-undergo-major-change/?ftag=TRE475558a=12825460=12819432=712355268
>
> What is terrifying is the SSH Problem. 9/10 hosts I interact with I do via
> ssh. And do we really need LUKS encrypted volumes for every user's $HOME
> directory? Sure for enterprise setups, etc.. but will there be a way to simply
> keep a normal unencrypted /home. How would scripts be able to backup certain
> work locations from user directories if the user is logged out?
>
Sytemd 245 is already released and is in Arch repos:
https://www.archlinux.org/packages/core/x86_64/systemd/
Arch already has an article on homed in the wiki that answers many of
your questions:
https://wiki.archlinux.org/index.php/Systemd-homed
or the upstream docs:
https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html
Notably:
"However, you must **enable and start** the systemd-homed.service."
(emphasis added)
"It achieves portability by moving all user-related information into a
storage medium, **optionally encrypted**, and creating an ~/.identity
file that contains signed information about the user - password, what
groups they belong to, UID/GID and other information that would
typically be scattered over multiple files in /." (emphasis added)
In short:
- It is already installed in your system, if it's up-to-date. I'm
assuming you did not notice any differences, right? That's because
- It's "opt-in" in the first place, and
- home directory encryption is *optional*, and
- it doesn't interfere with "traditional" (/etc/{passwd,group,shadow})
user databases.
There are a lot of systemd haters out there (still) that love to spread
plenty of FUD or half-accuracies about systemd. Generally speaking, your
best bet is to just simply explore the experience and documentation of a
distro that implements systemd properly (like Arch) and ignore anything
and everything you read in publications about it.
--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] teapot package could be improved
On 4/8/20 17:24, Jude DaShiell wrote: > which package has the version of rpc.h teapot needs to build? > Whichever package that is, the dependency is missing from the build > script. > You should probably instead post this on the AUR package's comment section, as it is an AUR package and the maintainer is much more likely to notice it there. https://aur.archlinux.org/packages/teapot/ -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] too many brick walls for graphical accessible environment on archlinux
On 1/6/20 04:05, Ralf Mardorf via arch-general wrote: > On Mon, 6 Jan 2020 02:45:53 -0500, Jude DaShiell wrote: >> I install gnome which has orca in it. The pulseaudio package installs >> along with all of its core gnome dependencies > > Hi, > > I don't know if this helps or might break Orca audio for GNOME. For > completely other reasons I'm using an empty dummy package to fulfil the > pulseaudio dependency of some apps. For my purpose it works without > issues since years. > > You could edit a PKGBUILD like this and build it using makepkg: > I suspect this would break configure/automake/etc. scripts that check for pulseaudio libs being installed and required via make flags in PKGBUILDS (and thus in depends/makedepends). probably fine if you don't plan on e.g. installing anything from the AUR, but probably not very good practice. i'd presume you're sitting on a timebomb, albeit minor, with pacman thinking pulseaudio libs are installed when they actually aren't. according to https://developer.gnome.org/platform-overview/unstable/tech-pulseaudio.html.en, pulseaudio is absolutely required for GNOME's audio API. On 1/6/20 02:45, Jude DaShiell wrote: > Next I run startx and get into gnome and try running orca. > All of the sudden none of the voice files festival was provisioned with > can be found anymore > and orca dies with an error. this sounds pretty suspicious to me. simply starting GNOME (which should probably be done with GDM, by the way) oughtn't be touching festival's voice files (assuming you're referring to the system-wide ones). if you mean your ~/.festivalrc, though, that's a possibility. what does: pacman -Qs 'festival-.+' return? -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] How to install archlinux using a specific parition of usb instead of the whole usb?
On 11/6/19 12:01 AM, Hongyi Zhao via arch-general wrote:
>> menuentry --hotkey=g 'Graphical install' {
>> set background_color=black
>> linux (loop)/install.amd/vmlinux vga=788 findiso=$iso_path components
>> --- quiet
>
> IMO, this is the most difficult thing to figure out a workable
> menuentry, I mean, the follownig code inserted here:
>
> findiso=$iso_path components
>
> And from where can I find the full manual for this? I have inspected
> the following webpage:
>
> https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
>
> And I cannot find out the parameters/arguments used here: `findiso'
> and `components'.
"findiso" and "components" are unique to Debian's initialization
scripts. The ones at
https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
are generic ones that the *kernel* uses, but others are used by the OS
itself during initialization. They're both passed to /proc/cmdline
(because it's the only reliable way of passing boot-time parameters to
runtime kernel operations and the initrd/initramfs).
"findiso" is documented here:
https://manpages.debian.org/testing/live-boot-doc/live-boot.7.en.html
As for "components", I have no idea what it does. You can extract the
ISO's initrd and check the init system in there, though, to find out.
> No, this is not the initial grub.cfg used by the iso when running in
> the efi mode which is the de-facto nowsdays. The first grub.cfg used
> by the iso is:
>
> /EFI/debian/grub.cfg
>
> This file will then source all of the other grub.cfg, including the
> one in /boot/grub/grub.cfg, which is the last grub.cfg in the chain.
All that does is call other cfgs and do insmods. Follow the "source"
directives and you will find that, yes, the one I mentioned is the menu
config (the one you actually want, because you want to create *menu
entries*) that is used by the Debian ISO.
You *definitely* will not be able to use the "linking"/parent configs
because they refer to paths inside the Debian ISO, not your USB drive.
--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] How to install archlinux using a specific parition of usb instead of the whole usb?
On 11/5/19 10:50 PM, Hongyi Zhao via arch-general wrote:
>> Are you using the appropriate kernel cmdline args in the menu entry?
>> They're different from Arch's grub loopback menu entry.
>
> This is just what I stucked on. I failed to figure out the correct
> cmdline args used for linux and initrd.
>
>>
>> https://wiki.debian.org/DebianLive/MultibootISO
>
> Useless. This is for Debian *live* instead of Debian *install* iso,
> the image I use for install Debian is:
>
> http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd64-DVD-1.iso
The live CD contains the installer. They're functionally the same, more
or less, and are created by the same tool/use the same init.
The only difference from that article is:
bootoptions="findiso=$iso_path boot=live components quiet splash"
would instead match the boot entry of the installer ISO. e.g. these are
directly from the install ISO's grub menu ([iso]/boot/grub/grub.cfg):
menuentry --hotkey=g 'Graphical install' {
set background_color=black
linux/install.amd/vmlinuz vga=788 --- quiet
initrd /install.amd/gtk/initrd.gz
}
menuentry --hotkey=i 'Install' {
set background_color=black
linux/install.amd/vmlinuz vga=788 --- quiet
initrd /install.amd/initrd.gz
}
(...)
SO you can either:
1.) Use the following:
set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso
loopback loop "$iso_path"
menuentry --hotkey=g 'Graphical install' {
set background_color=black
linux (loop)/install.amd/vmlinux vga=788 findiso=$iso_path components
--- quiet
initrd (loop)/install.amd/gtk/initrd.gz
}
menuentry --hotkey=i 'Install' {
set background_color=black
linux(loop)/install.amd/vmlinuz vga=788 findiso=$iso_path
components --- quiet
initrd /install.amd/initrd.gz
}
or even,
2.) Use the ISO's grub file directly:
set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso
loopback loop "$iso_path"
menuentry 'Debian' {
configfile (loop)/boot/grub/grub.cfg
}
But the latter is unlikely to work because again, that config is
expecting to be running grub itself so the paths are probably not going
to be correct.
I recommend instead using a generic name for the ISOs (e.g.
"debian.iso") so you don't need to edit/regenerate the grub.cfg for the
USB device every time you update the ISO.
--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] How to install archlinux using a specific parition of usb instead of the whole usb?
On 11/5/19 9:11 PM, Hongyi Zhao via arch-general wrote: >>> $ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 >> The ISO contains multiple partitions, so probably not. > > Why when using the whole usb disk, the problem will disappear? > As both Eli and I have both explained, because if you use the whole disk you're writing a partition table as *the partition table for the device*. If you try to write to a partition, you end up with nested partition tables. The .iso file is a *disk image*, not a *partition image*. >> Why are you >> trying to do this, precisely? > > I want to use a usb disk for installation of multiple distros, say, > Debian, Ubuntu, Arch, and so on. > In this case, I must not using the whole usb disk for only one iso, > and on the other hand, using whole usb disk for only one iso, is > wasting of the usb's space, considering that we cannot use it for > doing other things. Furthermore, I noticed that the dd-based method > is more robust than using the iso directly with grub's loopback > module. In what way? I do not agree with this. It's far easier to update the ISO, it's far easier to add new distributions to the bootloader (and both updating and adding new entries can even be done by regular users without granting disk reformatting permissions), etc. with grub loopback. > To say the least, for the Debian iso, the dd-based method can do the > trick while the loopback method will fail to detect the cd-rom during > the installation progress. Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry. https://wiki.debian.org/DebianLive/MultibootISO > >> >> Alternatively, you can use grub to boot an ISO *file* as a loopback >> device. Some people do this to create multiboot USBs. > > As I said above, this method is not so robust as the dd-based method. > In detail, the most robust method for using the usb disk to > installation a unix/linux OS, should be the dd-based method which > using the whole usb disk. But this method has the shortcoming that it > will occupy the whole usb disk with only a small iso image and > prohibit us for using the usb disk to do other things at the same > time. This seems highly subjective. What makes using DD superior to a loopback? It occupies the same exact disk space as if you dd'd to a partition except requires no modifications to the host disk. Now, if you *really* want to save space, you'd extract the squashed filesystems/initrds/kernels from each ISO you want to add and create grub entries that boot those directly, but that only affords you a couple extra megabytes per distribution. However, *that is not what grub loopback is*. Grub boots an iso file *directly*, with no modifications required. I guarantee it's far more maintainable and robust than any use of dd. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] How to install archlinux using a specific parition of usb instead of the whole usb?
On 11/5/19 8:41 PM, Eli Schwartz via arch-general wrote: > On 11/5/19 8:35 PM, Hongyi Zhao via arch-general wrote: >> Hi, >> >> I try to use a specific partition of usb to install archlinux, the >> following is the step: >> >> Suppose the /dev/sdc is my usb: >> >> $ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 > The ISO contains multiple partitions, so probably not. Why are you > trying to do this, precisely? Maybe you want to install archlinux > following the install guide, but installing to the USB partition instead > of an HDD. For example, > > https://wiki.archlinux.org/index.php/Installing_Arch_Linux_on_a_USB_key > > Alternatively, you can use grub to boot an ISO *file* as a loopback > device. Some people do this to create multiboot USBs. > As usual, Eli beat me to the punch. :) Really need to tell my MUA to fetch more frequently. As shown in my other reply, the .iso image has a partition table on it. Attempting to image this onto a partition leaves you with a partition table on a partition which is... *technically* possible, but parted/fdisk will complain about it (as they should, because we're talking about something that's "you goofed something hard or you have a REALLY technical, and probably very silly, reason to need nested partition tables"). Eli has a great suggestion about using Grub's loopback capabilities. I do this on my machines and it's saved my tuchas more than once, and highly recommend it even if you don't need it for install reasons. You can find instructions/information on it on the Arch wiki: https://wiki.archlinux.org/index.php/Multiboot_USB_drive#Using_GRUB_and_loopback_devices and I *very* recently even wrote briefly directly about this (using SystemRescueCD instead of the Arch ISO, but I mention it): https://sysadministrivia.com/news/howto-grubrescue -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] How to install archlinux using a specific parition of usb instead of the whole usb?
On 11/5/19 8:35 PM, Hongyi Zhao via arch-general wrote: > Hi, > > I try to use a specific partition of usb to install archlinux, the > following is the step: > > Suppose the /dev/sdc is my usb: > > $ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 > > Then I reboot my computer with the grub standalone bootloader and from > within the command line of grub, I do the following: > > Suppose the (hd2,2) is the partition which corresponding to the > /dev/sdc2, then I run the following commands: > > grub> set root=hd2,2 > grub> chainloader /EFI/boot/bootx64.efi > grub> boot > > But, the above step failed to boot, with the error similar to this in my ming: > > Failed to find the loader.efi > > OTOH, if I dd'ed the arch iso onto the whole usb disk like the following: > > $ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc > > Then, it will be successfully booted into the installation menu of > archlinux. So I want to know whether is is possible for me to use a > specific partition of usb instead of the whole usb disk for > installation archlinux? > > Regards > The biggest issue is this doesn't work because the ISO file *already has* partitions/a partition table on it (which is what lets you DD directly onto a block device rather than requiring partitioning of the target device first): [bts@cylon tmp]$ sudo kpartx -l archlinux-2019.11.01-x86_64.iso Warning: Disk has a valid GPT signature but invalid PMBR. Assuming this disk is *not* a GPT disk anymore. Use gpt kernel option to override. Use GNU Parted to correct disk. loop0p1 : 0 1300480 /dev/loop0 0 loop0p2 : 0 131072 /dev/loop0 164 [bts@cylon tmp]$ sfdisk -l archlinux-2019.11.01-x86_64.iso Disk archlinux-2019.11.01-x86_64.iso: 635 MiB, 665845760 bytes, 1300480 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x65cc13ea Device Boot Start End Sectors Size Id Type archlinux-2019.11.01-x86_64.iso1 *0 1300479 1300480 635M 0 Empty archlinux-2019.11.01-x86_64.iso2164 131235 131072 64M ef EFI (FAT-12/16/32) [bts@cylon tmp]$ parted --script archlinux-2019.11.01-x86_64.iso -- print Model: (file) Disk /tmp/archlinux-2019.11.01-x86_64.iso: 666MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End SizeType File system Flags 2 84.0kB 67.2MB 67.1MB primary fat16esp -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] rkhunter found possible rootkit
On 8/20/19 5:58 AM, Oliver Jaksch via arch-general wrote: > On Tuesday, 20 August 2019, 10:15:58 CEST you wrote: >> Am 20.08.19 um 10:00 schrieb Filipe Laíns via arch-general: >>> On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch via arch-general wrote: I let rkhunter running around once a week. There were nothing since many months. But today it's report complains about */lib64/libkeyutils.so.1.9* and therefore other tools they're (seems to be) using this SO. >> >> ... >> >>> No, those libraries are used for key manipulation, that's why rkhunter >>> thinks that they might be sniffer. >> >> In this particular case the filename was apparently used by a rootkit in >> 2013 and it was blacklisted. Now the legitimate owner of the >> libkeyutils filenames has reached the blacklisted version number. I >> don't know which of the two possibilities it is in your case. >> >> https://bugs.archlinux.org/task/63369 >> https://www.webhostingtalk.com/showthread.php?t=1235797 > > Thanks to all. I think the URLs Filipe has posted are the most expressive > part. Let's hope that this really is a false alarm coming from the past. > - > Oliver > If you're in doubt, you can also try chkrootkit. When dealing with potential false positives, it sometimes helps to try more than one tool. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Whatsapp group
On 8/14/19 1:04 AM, Ram Kumar via arch-general wrote: > Hey there archers, > How about creating whatsapp group along with this mailing list??.. > It will be usefull for beginners to get instant clarifications on their > doubts.. > > What do you think? > > Regards > Ramkumar > That's what the IRC channels are for: https://wiki.archlinux.org/index.php/Arch_IRC_channels Additionally, I'd strongly caution against Whatsapp: https://thenextweb.com/security/2019/08/08/whatsapps-chat-manipulation-exploit-remains-unresolved-even-after-a-year/ Plus its federated and closed-source/proprietary model (and it being owned by one of the largest and unscrupulous social media sites) is understandable cause for alarm for many individuals. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Proper use of signify in PKGBUILDs
On 7/21/19 4:40 AM, Ralf Mardorf via arch-general wrote: > On Sun, 21 Jul 2019 02:42:39 -0400, Eli Schwartz via arch-general wrote: >> The latter problem is why I'm incredibly frustrated by projects that >> use PGP, too -- when the only thing they sign is a file containing >> checksums, and not the actual source file. > > But it doesn't matter, since when the checksum is signed, it's more or > less the same as signing the source file/s, that's why almost all simply > sign a file containing one or more checksums. Why should this be > frustrating? If we are able to ensure that a checksum isn't faked, > IOW if can trust the checksum, than we are safe that a source file > passing a check against the proven checksum is correct, too. > i can't speak for why it bothers Eli, but it bothers me because that's exactly what GPG detached sigs are already: signed hash checksums. The signify method is a signed hash checksum of a (list of) hash checksum(s). To me it feels like an unnecessary abstraction when one could just provide .sig files for each file and be more widely compatible. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Is it secure to just sign repository databases?
On 6/16/19 5:03 AM, Manuel Reimer wrote: > Hello, > > I run a repository locally that I would like to share to the public. > > The build is mostly automated. That's why I don't want to sign each > individual package. The private key is not stored on the build machine > and I want to sign the resulting stuff externally. > > The easiest way would be actually to just manually sign the database > file. As this file includes all checksums of the individual packages, I > think this is as secure as signing every package, right? > > Thanks in advance > > Manuel theoretically, your thought process is sound. unfortunately, pacman doesn't verify like this (to my knowledge; someone feel free to correct me). but there's nothing necessitating you sign the package on the build machine, technically. you could fetch the repo DB, grab the checksums inside (i believe they contain a metadata tree and .PKGINFO; been a while since i explored the format), fetch the package itself into memory, and if the checksum matches, you can create a detached signature from that item in memory, then upload that signature. (i think? you might meed to regen the repo.db; not sure if it tracks sigs.) there is, of course, the trouble of not being able to cryptographically verify the integrity of the checksums inside the repo DB (since the packages are being fetches from a remote source and *technically* possibly could have been tampered along with the repo DB). this is why signing is done at build time - it at least removes that vector (notwithstanding local tampering, but that's time-sensitive and a dedicated build box separate from a repo server is a lot more resistant). i can create a python PoC of this if that'd be easier to understand of the "remote signing". BUT. TL;DR "pacman doesn't work like that" and it's generally safer practice to build and sign (and build a repo db) on a different box, then push to the repo server. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] HTTP spam from China - CIDR compacting tool
On 2/26/19 1:20 PM, Genes Lists via arch-general wrote:
> On 2/26/19 1:13 PM, Juha Kankare via arch-general wrote:
>> On 26/02/2019 20:11, Genes Lists via arch-general wrote:
> ...
>>
>> My current script is just pulling cn.zone from ipdeny.com. This looks
>> super useful, I'm saving it. Thank you dude!
>>
> You're welcome.
>
> I just ran it on cn.zone and it reduces the number of lines from 8,337
> to 5,120. It can make a significant difference.
>
> best,
>
> gene
>
Just to +1 what Gene has said, I've taken similar approaches to
compacting into CIDRs and it really does make a significant difference.
For clarification on his ipset[0] point, I also have to strongly
recommend it. It not only *greatly* simplifies your ruleset, but it can
be dynamically altered without needing to reload your firewall rules.
e.g. assuming you have an IP set named "china_ips",
-A INPUT -m set --match-set china_ips src -p tcp -m tcp --dport 80 -j DROP
will drop traffic for all those entries. You've then simplified many
(MANY) rules to one. :)
You can (Gene, you may find this particularly useful since you feed to
ipset) use the pyroute2.IPSet() function to actually manage the live
kernel's ipsets as well. Make sure your running kernel and latest
installed kernel match, otherwise you'll need to reboot so the ipset
kernel module can be loaded.
Untested, but should be pretty darn close if not functional:
#
import subprocess
import pyroute2
# (...)
ipset = pyroute2.IPSet()
setsfile = '/etc/ipset.conf'
setname = 'china_ips'
tmpset = '{0}_TMP'.format(setname)
set_exists = False
try:
# Check to see if the list exists.
ipset.headers(setname)
# list is done here as a quick-and-dirty sanity/exception check,
# which is why it's in both the try and exception.
setlist = ipset.list(name = setname)
set_exists = True
except pyroute2.ipset._IPSetError:
ipset.create(setname, stype = 'hash:net')
setlist = ipset.list(name = setname)
# We use a temporary set so we don't affect any current iptables
# processing. Most likely unnecessary, but better safe than sorry.
try:
ipset.destroy(name = tmpset)
except pyroute2.ipset._IPSetError:
# It doesn't exist (yet), which is what we want.
pass
# Create the temporary set
ipset.create(tmpset, stype = 'hash:net')
for n in set1.iter_cidrs(): # "set1" is from Gene's script
ipset.add(tmpset, n)
# Make the temporary set live
ipset.swap(setname, tmpset)
# And cleanup the now-unnecessary tmpset
ipset.destroy(name = tmpset)
# Save them to the persistent file so it's applied on a reboot.
# Remember to "systemctl enable ipset.service".
# Unfortunately, there isn't a built-in save function.
# You could easily write your own iterator/generator, though,
# if you want to avoid a subprocess call.
# The syntax is pretty simple.
with open(setsfile, 'w') as f:
ipset_cfg = subprocess.run(['/usr/bin/ipset',
'save'],
stdout = f)
# DONE.
#
[0] https://wiki.archlinux.org/index.php/Ipset
--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] BrlTTY Hard Dependancy on eSpeak
On 2/13/19 6:24 PM, Levente Polyak via arch-general wrote: >> really? >> >> the section i linked to claims this: >> >> "The espeak speak_lib.h include file is located in >> espeak-ng/speak_lib.h >> *with an optional symlink in espeak/speak_lib.h*. This file *contains >> the espeak 1.48.15 API*, with a change to the ESPEAK_API macro to fix >> building on Windows and some minor changes to the documentation >> comments. *This C API is API and ABI compatible with espeak.*" >> (emphasis >> added) >> >> granted, we have espeak 1.48.04 in [community], but 1.48.15's been >> development status since 2015[0]. i have a hard time imagining that >> 1.48.04's API and ABI have had breaking changes on what seems to be a >> single patch level release, and one four years old at that. >> >> >> >> [0] http://espeak.sourceforge.net/test/latest.html > > Then I'm sorry to tell you that's indeed the case. > Look at espeak package history, the epoch is > there for a reason. It was tried to be a drop in > replacement before and had to be reverted. > > I still have plans to transform espeak back to the > NG variant, but that needs a bit of time, staging > and planning. For time being you need to accept > it doesn't work that easily. > well that is *incredibly* disheartening and surprising. thanks for the helpful response, levente. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] BrlTTY Hard Dependancy on eSpeak
On 2/13/19 5:18 PM, Doug Newgard via arch-general wrote: > On Wed, 13 Feb 2019 15:25:19 -0500 > "brent s." wrote: > >> On 2/13/19 3:16 PM, Storm Dragon via arch-general wrote: >>> Hi, >>> >>> I'm having some issues with installing brltty. The problem is, it >>> depends on espeak but I'm using the espeak-ng from community and it is >>> giving me the unresolvable conflicts problem for that reason. >>> >>> I don't think that brltty actually needs espeak at all, and it could >>> probably be listed as an optional dependancy along with espeak-ng. >>> >>> Thanks, >>> Storm >> >> hopefully polyzen is on this list. >> >> polyzen- >> >> any reason why you couldn't add espeak to espeak-ng's provides? seems >> like it's mostly compatible, at least from the interface and lib level: >> >> https://github.com/espeak-ng/espeak-ng#espeak-compatibility >> > > Libs are different, so it's not a drop-in replacement. Provides would be > incorrect. > really? the section i linked to claims this: "The espeak speak_lib.h include file is located in espeak-ng/speak_lib.h *with an optional symlink in espeak/speak_lib.h*. This file *contains the espeak 1.48.15 API*, with a change to the ESPEAK_API macro to fix building on Windows and some minor changes to the documentation comments. *This C API is API and ABI compatible with espeak.*" (emphasis added) granted, we have espeak 1.48.04 in [community], but 1.48.15's been development status since 2015[0]. i have a hard time imagining that 1.48.04's API and ABI have had breaking changes on what seems to be a single patch level release, and one four years old at that. [0] http://espeak.sourceforge.net/test/latest.html -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] BrlTTY Hard Dependancy on eSpeak
On 2/13/19 3:16 PM, Storm Dragon via arch-general wrote: > Hi, > > I'm having some issues with installing brltty. The problem is, it > depends on espeak but I'm using the espeak-ng from community and it is > giving me the unresolvable conflicts problem for that reason. > > I don't think that brltty actually needs espeak at all, and it could > probably be listed as an optional dependancy along with espeak-ng. > > Thanks, > Storm hopefully polyzen is on this list. polyzen- any reason why you couldn't add espeak to espeak-ng's provides? seems like it's mostly compatible, at least from the interface and lib level: https://github.com/espeak-ng/espeak-ng#espeak-compatibility -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Kpartx should be in the repos and archiso for enabling encrypted GPT install
On 1/13/19 10:38 PM, y...@marupa.net wrote: > > No need to use the luksHeaderRestore/luksHeaderBackup. You can create > and use a detached LUKS header with the --header parameter. You can use > --header, combined with a zero offset on the device and no partition > table and it should, in theory, only look like random data across the > entire drive. You could then put LVM on the LUKS container for > "partitioning." hey, cool! cheers, i wonder when they added that! > > I use a setup like that, though I'm not sure how bootable that setup > could be; especially on UEFI systems which require an unencrypted > system partition. > once the bootloader loads your initrd, the initrd would be able to re-assemble it provided the data source for the header was available. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Kpartx should be in the repos and archiso for enabling encrypted GPT install
On 1/13/19 10:19 PM, brent s. wrote: >> Well, unencrypted partition table. What he wants is an encrypted >> partition table, and more generally no metadata available (so the disk >> just looks like plain garbage, not x nice labelled partitions with LUKS >> headers). also, the LUKS header is still there whether it's on the partition or the whole disk. you're in no way obligated to reveal that information in the GPT's partition type with 7FFEC5C9-2D00-49B7-8941-3EA10A5586B7 identifier. linux doesn't care what the partition type is labeled as, functionally, except to determine auto-raid, unused partitions, and LVM partitions. OP said they're using plain dm-crypt, however, which *doesn't have* LUKS headers. no matter if it's whole-disk or partition. the only way you can get around that is with a luksHeaderBackup to a separate source and then a luksHeaderRestore when you want to use it. but don't take my word for it. https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects section 5.2. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Kpartx should be in the repos and archiso for enabling encrypted GPT install
On 1/13/19 5:43 PM, Bruno Pagani via arch-general wrote: > Le 13/01/2019 à 23:27, Eli Schwartz via arch-general a écrit : >> The more complex method would be to copy the initramfs encrypt hook and modify it to support an additional encrypted device with a different password. >>> I want full disk encryption. There is nothing controversial about FDE, >>> it is already covered in the Wiki, except that I want FDE without LVM. >> You can have FDE without LVM today, using the suggestion I just provided >> and you ignored. >> >> Unless you mean that it's not really FDE if attackers can read the >> partition table layout, in which case LVM is not valid as FDE and you'd >> better buy yourself some proprietary hardware-encrypted solution. > > Readable partition table layout is exactly the issue (and you answered > yourself about your LVM mistake). > plausible deniability only works if it doesn't look like you're hiding something. given the mention of wanting to encrypt /, i'm assuming this is intended to be a live OS. that means you still need unencrypted boot code in *some* form, even if you use [0] or [1]. sure, you can keep your boot code on a separate USB dongle or what have you, but for UEFI that entry is still going to be in there (unless you're booting to an EFI shell and manually booting every time). hence my "increasing headache tenfold" comment earlier. >> But I still do not understand what practical benefits you are seeking >> that are not solved by having multiple encrypted partitions on an >> unencrypted partition table. > > Well, unencrypted partition table. What he wants is an encrypted > partition table, and more generally no metadata available (so the disk > just looks like plain garbage, not x nice labelled partitions with LUKS > headers). see above. FDE, even "full" FDE, is not a magic bullet. if your threat model is so serious that you're worried about people *knowing* you have an encrypted disk, OpSec is going to save you more than encryption. otherwise, FDE's just one *part* of a robust security protocol. generally speaking, when your threat model is that of the above, it's *far* better to: - have a "normal-looking" OS installed on the computer with some (fake) photos of "family", some fake documents here and there, some fake browsing history, etc. on... - an unencrypted system partition - and use a separate easily physically hidden (encrypted) actual OS on a thumbdrive - with *access* to a remote resource that has your real data, not the real data on the thumbdrive itself and then throw that entire kit away after whatever operation you've done is complete and you're back in a safe zone and never use it again. that's a lot less suspicious (and a lot less likely to attract attention to yourself - the very LAST thing you want if you truly believe and are a valuable target) than walking around with a device that's obviously being used yet has a disk full of what looks like random data. however, if you're just trying to prevent against joe blow getting your ssh keys in case your laptop gets stolen or lost, encrypting the partition table gains you nothing except unnecessary work. ROI. [0] https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_(GRUB) [1] https://github.com/xmikos/cryptboot -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Kpartx should be in the repos and archiso for enabling encrypted GPT install
On 1/13/19 2:26 PM, Neven Sajko via arch-general wrote: >> pardon for asking, but why in the heck would you want to partition the >> encrypted volume? that is going to cause tenfold headache for you down >> the road. >> >> -- >> brent saner >> https://square-r00t.net/ >> GPG info: https://square-r00t.net/gpg-info > > I need one partition for swap and one for the filesystem mounted on /. > also worth noting, your system clock is an hour ahead of what it should be -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Kpartx should be in the repos and archiso for enabling encrypted GPT install
On 1/13/19 2:26 PM, Neven Sajko via arch-general wrote: >> pardon for asking, but why in the heck would you want to partition the >> encrypted volume? that is going to cause tenfold headache for you down >> the road. >> >> -- >> brent saner >> https://square-r00t.net/ >> GPG info: https://square-r00t.net/gpg-info > > I need one partition for swap and one for the filesystem mounted on /. > that... doesn't answer my question. fundamentally, and structurally, why do you think you want this instead of GPTing the disk itself and applying dm-crypt to the partitions? so, you know, it works with bootloaders. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Kpartx should be in the repos and archiso for enabling encrypted GPT install
On 1/13/19 2:03 PM, Neven Sajko via arch-general wrote: > To clarify, I am talking about something like this, but with GPT instead of > LVM: > > https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt > pardon for asking, but why in the heck would you want to partition the encrypted volume? that is going to cause tenfold headache for you down the road. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] List of Files Created by makepkg
On 12/7/18 10:13 AM, Jayesh Badwaik via arch-general wrote: > Hi, > > I am trying to write an automated script which takes in packages and package > files created by makepkg and uploads it somewhere. > > For this, I would need the list of files created by the `makepkg` command. Is > there a way to get that? > you mean files *in* the .pkg.tar.xz? that get installed to the filesystem during installation? they're.. just tar files. you can either tar -tvf file.pkg.tar.xz or just use whatever library (e.g.g tarfile on python) to do this. the entire tree is there alternatively, you can just extract the .MTREE file inside the package tarball. if you mean you want a list of .pkg.tar.xz files that would be CREATED by makepkg you could just read the man page for makepkg: --packagelist List the package filenames that would be produced without building. Listed package filenames include PKGDEST and PKGEXT. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem install shrew vpn client
On 11/2/18 5:25 PM, Peter Bauer wrote: > Am 26.09.18 um 10:47 schrieb Maykel Franco via arch-general: >> Hi, I received this error when compile the program shrew vpn client: >> >> yaourt -S shrew-vpn-client >> >> /tmp/yaourt-tmp-maykel/aur-shrew-vpn-client/src/ike/source/libike/manager.file.cpp: >> In member function 'bool _CONFIG_MANAGER::file_pcf_load(CONFIG&, const >> char*, bool&)': >> /tmp/yaourt-tmp-maykel/aur-shrew-vpn-client/src/ike/source/libike/manager.file.cpp:682:19: >> error: aggregate 'EVP_CIPHER_CTX ctx_cipher' has incomplete type and >> cannot be defined >> EVP_CIPHER_CTX ctx_cipher; >>^~ > > should this even be answered here? > > https://github.com/openssl/openssl/issues/962#issuecomment-427752560 > > TLDR; > > >>> So, all existing Software must be rewritten just to be able to use > 1.1.x ? >>> Do you have any idea how many Million lines of code are affected by > this crap?? >> Yes, applications must be changed to use 1.1.x. for what it's worth, you may be able to use vpnc[0] or StrongSwan[1] as an IPSec client. this may be even recommended, as Shrew Soft hasn't released an update for 5 years. that being said, the dependencies for the PKGBUILD should be changed to use openssl-1.0[2] instead of openssl. you may need to further update the cmake line (or patch the CMakeLists.txt) to point explicitly to the proper openSSL path (for openssl-1.0 instead of the default-provided v1.1.x), but i'm not as familiar with cmake to recommend how to do this. honestly, i'd recommend just moving away from Shrew Soft if possible and instead use something that is actively maintained. I strongly recommend StrongSwan. [0] https://wiki.archlinux.org/index.php/Vpnc [1] https://wiki.archlinux.org/index.php/StrongSwan [2] https://www.archlinux.org/packages/core/x86_64/openssl-1.0/ -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Install Archlinux on HP Elitebook
On 12/18/2017 09:36 AM, n...@contrepoison.ch wrote: > Hi everyone, > > I'm struggeling with my laptop : I can't manage to boot into any Linux > distribution. > My laptop is an HP Elitebook x360 G2 ; BIOS P80 01.09 Rev.A (up to date). > By turning off every "protection" I'm able to select the USB stick in > the boot menu ; but I can't pass this step. I immediately go back to the > boot menu. > > Does anyone knows how to install Arch on one of thoose #@$&=%* machine ? > > Many thanks, Tom I'm assuming you tried following this? https://wiki.archlinux.org/index.php/USB_flash_installation_media#BIOS_and_UEFI_bootable_USB -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info signature.asc Description: OpenPGP digital signature
Re: [arch-general] Login Statistics Similar to Centos
On 09/01/2017 02:38 PM, William Gathoye wrote: > I already did knew about this PrintLastLog feature but I wasn't aware > this was PAM responsible of that (I thought this was sshd looking in > wtmp or lastlog manually). > > Btw, do you know how to achieve the same behavior but on TTY or in GUI > opening a shell console (then added in the shell conf, like bashrc)? Do > you think we need to parse the output of the "last" command manually, or > do you have any other solution avoiding to reinvent the wheel? > See my last reply. the lastlog stats will print for both TTY and SSH. (From recollection, though, sshd's PrintLastLog is different from PAM's lastlog printing.) Anyways, no need to much about with bashrc. PAM itself prints the lastlog if that module's loaded. I assume. as for a desktop environment... that's a whole 'nother ballgame. You'd want to hook into the messaging/notification system for the DE in that case. -- brent saner https://www.square-r00t.net signature.asc Description: OpenPGP digital signature
Re: [arch-general] Login Statistics Similar to Centos
On 09/01/2017 02:11 PM, William Gathoye wrote: > > > On 08/30/2017 12:19 AM, Leonid Isaev via arch-general wrote: >> >> man 8 pam_lastlog > For your kind info, calling pam_lastlog.so like described in the man > pages is segfaulting on my side. > > $ /usr/lib/security/pam_lastlog.so > Segmentation fault (core dumped) > > I cannot debug further since it hasn't been build with gdb debug > symbols, but this is likely to this issue. [1] > > > [1] https://www.redhat.com/archives/pam-list/2014-August/msg3.html > You don't execute pam_lastlog.so directly. [root@centos7test pam.d]# pwd /etc/pam.d [root@centos7test pam.d]# cat login #%PAM-1.0 auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so auth substack system-auth ***auth include postlogin accountrequired pam_nologin.so accountinclude system-auth password include system-auth # pam_selinux.so close should be the first session rule sessionrequired pam_selinux.so close sessionrequired pam_loginuid.so sessionoptional pam_console.so # pam_selinux.so open should only be followed by sessions to be executed in the user context sessionrequired pam_selinux.so open sessionrequired pam_namespace.so sessionoptional pam_keyinit.so force revoke sessioninclude system-auth ***sessioninclude postlogin -session optional pam_ck_connector.so (*** prefixed for emphasis. Do not actually put those in a pam config.) [root@centos7test pam.d]# cat postlogin #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet ***session [default=1] pam_lastlog.so nowtmp showfailed ***session optional pam_lastlog.so silent noupdate showfailed (*** prefixed for emphasis. Do not actually put those in a pam config.) As shown, pam is calling the pam_lastlog.so object (which is why you can't execute it; it's not an executable, it's a Shared Object). To do this over SSH, /etc/ssh/sshd_config has UsePam yes (and PrintLastLog yes is enabled by default) -- brent saner https://www.square-r00t.net signature.asc Description: OpenPGP digital signature
Re: [arch-general] Increase console size regardless of screen size
On 08/27/2017 10:14 AM, Storm Dragon via arch-general wrote: > Howdy, > I am blind, and don't even have a screen connected to this computer. For > some reason, my console size is 30 lines and 80 columns. I've not seen > this small of a console before. they usually have 50+ lines and over 100 > columns. > > I have searched for quite a while, but not found anything about > increasing the console size. I did find a python script that will set > the screen to the actual size, but it returns 30 80 as well, so no luck > there either. One site said you could just export the lines and columns > you want, but that failed, even though the variables were set correctly. > > Is there any way to set the lines and columns regardless of the size > your computer believes the screen to be? > Thanks for any help, > Storm Storm- Is this on a braille display via brltty? Or via a screen reader/TTS/speech synthesizer? If the former, which model is your braille device? I have noticed this issue before with VGA framebuffer resolutions (or KMS mode resolution) being less than ideal, but I'm not quite sure if brltty does translations *from* the VGA or if it occurs at a lower level and emulates a VGA display to the kernel. I unfortunately have no experience with this or frame of reference and no devices to test with either, but I'd say I'm intrigued by how it handles this. If brltty does appear as a VGA device to the kernel, I should note that 80x30 is a standard mode of grub legacy (specifically, mode 0f05 or type 4). However, unless you specifically installed and configured your system to use grub legacy, I can't see that being relevant. I would try setting: GRUB_GFXMODE=1024x768x24 # or whatever the max resolution is? # start conservatively and work your way up GRUB_GFXPAYLOAD_LINUX=keep in /etc/default/grub and re-running grub-mkconfig -o /boot/grub/grub.cfg to see if this makes any difference either way in how it renders to however you're interacting with it. Best of luck; do please keep us posted, as I've never interacted with vision-impaired terminals before so this is new territory for me. -- brent saner http://www.square-r00t.net signature.asc Description: OpenPGP digital signature
Re: [arch-general] AIF-NG (feedback/Request for Comments)
On 05/08/2017 11:46 AM, Bart De Roy via arch-general wrote: > Thank you for sharing! I could try AIF-NG and some of > your other projects in a few weeks on an old laptop. > > The link to the kernels 'submitting patches' document > has changed to > https://www.kernel.org/doc/Documentation/process/submitting-patches.rst > Thank you Bart! Both for offering to test test and the updated link; I'll push updates to my docs accordingly. -- brent saner https://www.square-r00t.net signature.asc Description: OpenPGP digital signature
[arch-general] AIF-NG (feedback/Request for Comments)
Hello! Some of you may remember AIF (Arch Installation Framework). However, the project is dead ([0]) and has been for quite some time. Being that most major distributions have a way of installing their distribution in an unattended manner/via PXE: -Debian (and derivatives, incl. Ubuntu): preseed -RHEL/CentOS/SuSE (and derivatives): kickstart (cobbler, etc.) I felt that Arch would benefit from something similar. As such, I have written AIF-NG[1]. It's written in python 3 and uses an XML-driven configuration (see the documentation[2] for details[3]). I would welcome feedback on this (preferably via my bugtracker[4] unless it happens to be discussion-oriented), as I'd like to get it mature enough to propose it for inclusion in the official Arch install media (currently for this to be supported, that would only require two things: the "python" and "aif" (or "aif-git") packages, which can be found on the AUR[5][6]). [0] https://github.com/Dieterbe/aif [1] https://git.square-r00t.net/AIF-NG [2] https://aif.square-r00t.net/ [3] https://aif.square-r00t.net/#writing_an_xml_configuration_file [4] https://aif.square-r00t.net/#bug_reports_feature_requests [5] https://aur.archlinux.org/packages/aif/ [6] https://aur.archlinux.org/packages/aif-git/ -- brent saner https://www.square-r00t.net signature.asc Description: OpenPGP digital signature
