*Digit_ sees guix.el and :.) *jgrant ordered a RYF-compliant Wireless-N adapter today, so he can drop this bulky Wireless-G'r that he's bee dealing with for far to long. :^) <jgrant>Yeah, I'm pretty excited in that I can take this machine with me soon without worrying of accidently breaking this/the adapater as previously I've concerned myself with. ***Digit_ is now known as Digit
<jgrant>Okay, I'll likely look into setting up a torrent for GSD tomorrow if Gabou doesn't beat me to it. :^) <Digit>my browser seems to think i've opened that in the past at least. thanks, that's got me diving in, rather than all the reading around the edges. :) <ewemoa>cool -- it's hard to know what to ignore at first! <ewemoa>ahhh, /root/.config/guix ... that's where things are hidden :) <mark_weaver>ewemoa: that guide is outdated in some ways and has some mistakes also. <mark_weaver>(we used to use /nix/store, but now we use /gnu/store) <mark_weaver>(which also works, but is more typing than you need) <mark_weaver>~/.config/guix is where the updates from "guix pull" go. <mark_weaver>I don't use "guix pull", but instead prefer to run directly out of my git checkout using ./pre-inst-env <mark_weaver>and remember that the daemon is normally the only thing that you run as root. <ewemoa>mark_weaver: thanks for the diffs! <mark_weaver>can 'patch' be updated in master, or is that for core updates? <Gabou>jgrant | Okay, I'll likely look into setting up a torrent for GSD tomorrow if Gabou doesn't beat me to it. :^) <Gabou>Digit: thanks for the video conference :-) <civodul>indeed, that sounds like a nasty vulnerability <ewemoa>what is the following missing for building a new package in an installation of gsd 0.8.1 running on virtualbox? 1. create appropriate test.scm file 2. in same dir, guix build -L . test.scm <jpt4>I write to report a successful GSD install and boot, and to ask a question about user passwords. <jpt4>It strikes the security conscious as imprudent to store passwords as plaintext in the main system /etc/config.scm, but using unix "passwd" to write to .shadow bypasses guix. <jpt4>Is this a necessary divergence, or can guix access and manipulate encryted data as part of a system configuration? <jpt4>E.g., could the (password) field reference a file like .shadow? <jpt4>I am further curious whether anyone has successfully experimented with disk encryption on GSD, since the installer now comes with dm-crypt. <jpt4>Greetings, #guix guix (few organizations can claim to be so demonymous). <sir123>Hey, i have burned a USB ISO and have booted into the live, but dhclient reports unknown interface: No such device! What can I do? <DusXMT>We use eudev, it names network devices differently than classic udev <sir123>Ok, there's quite a bit, sorry I'm using my Replicant phone <DusXMT>Scrolls off screen? In that case, ifconfig -a | less <civodul>sir123: the ethernet device is typically called "eno1" if you have a single Ethernet card in your machine <civodul>i think the manual erroneously mentions "eth0" somewhere <civodul>yeah, i noticed it a while back but forgot to fix <sir123>No, but I'm not particularly fast, sorry. Three parts: a link encap:ethernet, a link encap:local loopback and a wlp3s0 link encap:ethernet. I'm using a wireless card that I know works under free software <sir123>Ok, link is not ready, waiting... <sir123>Thank you for this distro too, it looks great! <sir123>And back to prompt, what should i do? <jpt4>Are you connected to a network? <sir123>No, my wireless card doesn't even seem to be initialized yet <DusXMT>sir123: you might have to use wpa_supplicant, I don't know if it's on the installer system though <sir123>I don't think the kernel knows about it, tbh <jpt4>wpa_supplicant, that is. <jpt4>What kind of wireless are you trying to access, sir123? <civodul>sir123: many wifi cards require non-free firmware, which is not provided <civodul>you need either an ath9k-based wifi card, or a good'ol ethernet card <sir123>A local router, and it has worked under Parabola, Trisquel, etc. <sir123>I've tried this on other GNU/Linux FSF approved systems before <jpt4>You may try writing your own wpa_supplicant.conf. <civodul>sir123: i gave suggestions above :-) <civodul>could you tell us what your wifi card is? <sir123>Can't I lspci it? Sorry, I cant remember <sir123>The first two are empty, wlp3s0 reports mode:managed, access point not-associated, etc <jpt4>lspci | grep 'Network controller' will give your wi-fi card. <civodul>sir123: so you need to configure wlp3s0 with 'iwconfig', 'iw', or 'wpa_supplicant' <civodul>ATM it's up to the user to configure the network interface <sir123>Ok, Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter <civodul>let's say you have a wifi network called "mynet" without password, you can first run "ifconfig wlp3s0 up && iwconfig wlp3s0 essid mynet key off" <sir123>Perfect! Thank you guys so much! Its DHCPDISCOVERing <sir123>Uh, it's saying 'Error for wireless request "Set Encode" (8B2A) <jpt4>Is the network password protected? <sir123>Not literally, i did put the password in, yes <jpt4>'iw dev wlp3s0 scan' will report the visible wi-fi networks. <jpt4>For your desired net, what does the "Authentication Suites" field say? <sir123>Its spitted out a bunch of data, i need to scroll up <jpt4>| less is a terminal's best friend. <sir123>Oh wait i can grep it im an idiot <jpt4>Very good. Have you written a custom wpa_supplicant.conf file before? <jpt4>Unfortunately, the GSD install doesn't have the man page for wpa_supplicant.conf. <jpt4>So here is the file, line by line: <ewemoa>answering my own question: helps to have the right path when specifying -L <jpt4>'wpa_supplicant -B -Dnl80211,wext -iwlp3s0 -c/etc/wpa.conf' <civodul>ewemoa: assuming test.scm is in the current directory, you should be able to run "guix build -L . foo", where "foo" is a package defined in ./test.scm <jpt4>i for interface, c for conf file <sir123>Its throwing back its usage reference <jpt4>Aside from the -D, it should be similar to the example at the bottom of the help output. <jpt4>The generic linux wireless driver. <sir123>How should I try that? I don't think linux picked it up <ewemoa>civodul: thanks, unfortunately with . (this was inside a guix/gnu/packages dir) i kept getting 'unknown package', somehow specifying the guix/ ancestor dir as the path seems to work better... <sir123>wpa_supplicant -Dwext -wlp3s0 -c/etc/wpa.conf <jpt4>sir123, you need the flag '_B', and '-iwlp3s0'. <jpt4>The lack of spaces is more difficult to parse. <sir123>And it has rejected every line of the config. <sir123>Was it all meant to be on one line? Sorry <jpt4>I don't know if it matters, but it was intended to be newline delimited. <sir123>Link is ready! Thank you guys so much! <jpt4>You are welcome. I am new to GSD as well, glad to see another convert. <sir123>Congratulations on being FSF certified, btw. <jpt4>The template config in the docs <jpt4>is suboptimal in my experience. <jpt4>There are a few better examples on the internet <jpt4>paste.lisp.org/display/145510 <jpt4>permalink.gmane.org/gmane.comp.gnu.guix.devel/5589 <jpt4>If any more experienced users have better recommendations, I would greatly appreciate them. <jpt4>Good luck sir123, may your next irc visitation be from a GSD machine. <sir123>Goodbye, thank you! I am in your debt! <davexunit>jpt4: what's suboptimal about the example config? <jpt4>It is quite spartan, to the point of not demonstrating useful config syntax. <davexunit>I think we could change the example to be more helpful, provided that it remains simple. <davexunit>just curious about what you'd like to see explained. <jpt4>Without the examples I linked <jpt4>I wouldn't have known how to more fully configure a user account. <jpt4>This may be a deficit in my reading of the documentation. <davexunit>jpt4: the user account API is described in section 6.5.2 <jpt4>Also, not having a (packages) field discomfitted me until I saw the above examples. <jpt4>Thank you for the reference. <jpt4>6.2.1 has a better example. <jpt4>(Which I now recall reading at some point.) <jpt4>"'Fluxbox is a X window amanger'" <jpt4>Thank you, ewemoa, this is a fine benchmark for my own packaging efforts. <davexunit>jpt4: there's lots of good examples in gnu/packages/ <bavier`>pastee.org has an expired certificate <ewemoa>davexunit: guix build seemed to produce something and guix package -i seemed to put something in my path <jpt4>davexunit: Thank you. When is it appropriate/necessary to write a package module vs. a package? <ewemoa>yes, it does seem to have an expired cert <davexunit>ewemoa: that's a good sign. now try using it and see if it actually works. <ewemoa>davexunit: windowmaker seemed to block my efforts and it's time for sleep :) <davexunit>jpt4: we use modules to group related packages to the best of our ability. you should try to fit your package into an existing module, if one of them makes sense. <jpt4>Very well. It seems like certain packages are their own modules, however. Lynx, for instance, was an undefined variable until included within (use-package-modules). <davexunit>jpt4: yes, some modules contain only a single package. <bavier`>a loose convention is to put GNU packages in their own module <jpt4>Are packages are strictly contained within package modules? <davexunit>our convention is that they live in the (gnu packages ...) namespace. <jpt4>Such that a package can not be specified under (packages) if its module is not in (use-package-modules)? <davexunit>yes, you must import the module that contains the relevant package variables. <davexunit>use-package-modules is just sugar for importing modules from the (gnu packages *) namespace <davexunit>the module system is how we compartmentalize code in Guile. <davexunit>in Guix, packages are just scheme objects, and the ones you are referencing in (packages ...) have been assigned to scheme variables that you've imported. <jpt4>I will re-read 6.2 of the guide, now that I have an underlying GSD system to reference. <jpt4>Again, I do hope to contribute to GSD/guix, and thank you and the rest of the developers for building this project. <bavier`>jpt4: Thank you for your interest. :) <sir123>Im having trouble with the os config <sir123>It keeps saying end of file in string constant <mark_weaver>jpt4: regarding passwords in the OS config, actually it's the crypted passwords that go there, the same as you'd see in /etc/shadow <jpt4>sir123, that indicates an excess of parens terminating an expression before its time. <jpt4>mark_weaver: Is there a guix utility to create encrypted passwords akin to passwd, or will they live in both shadow and config.scm? <mark_weaver>civodul: are you sure that 'eno1' is typically the name of the ethernet device? on my Libreboot X60 it's enp1s0 <mark_weaver>jpt4: I don't think we currently have that, sorry. lots to do. you can just copy it out of an /etc/shadow file you already have, I guess. <mark_weaver>but maybe there's a better way that I don't know about. <mark_weaver>you can also just leave the password field out and run 'passwd' after first installation. <mark_weaver>updating the system later (the common case) doesn't overwrite existing users. it just adds any that are missing. <davexunit>does NixOS do the same? I question that behavior. <jpt4>mark_weaver: Certainly, though if a more unified approach exists, it would be preferable. <davexunit>I worry about the statefulness of stuff like that. <civodul>davexunit: the problem is that user accounts are inherently stateful <fchmmr><mark_weaver> civodul: are you sure that 'eno1' is typically the name of the ethernet device? on my Libreboot X60 it's enp1s0 <fchmmr>mark_weaver, civodul does guix use systemd? <civodul>there's a lot of state associated with user accounts, such as home directories <mark_weaver>jpt4: there's almost certainly some utility somewhere that does that job. <davexunit>civodul: well the home dirs don't have to go, but do they remain in /etc/passwd? <fchmmr>mark_weaver, ok, so dmd has similar NIC device naming schemes to systemd? <civodul>davexunit: currently yes; maybe we could change that, dunno <mark_weaver>davexunit: if you really want to avoid all statefulness, you can run 'guix system init' on a fresh partition instead of 'guix system reconfigure' <davexunit>I want my database to not be wiped when I reconfigure. <davexunit>but then again, I don't specify the creation of my database in my OS config file <civodul>so really, what to do with user accounts is an open question i think <civodul>maybe removing them would be nice, indeed <mark_weaver>fchmmr: it's not dmd. it's eudev that names the devices. eudev is gentoo's fork of udev, since udev is now part of systemd. <fchmmr>wow, I didn't know gnutoo did that. he's involved in a lot of free software projects it seems, all low level <mark_weaver>I'm pretty sure that we could configure user-specified aliases for those devices. <mark_weaver>udev configuration files provide a lot of flexibility <jpt4>civodul: User attributes may be mutable, but they are also portable. If a particular mutation is deemed canonical, e.g. by specification in a system wide config file, transplanting the config to a different machine should reproduce exactly the state at the time of specification. <civodul>jpt4: that's what happens: 'usermod' is run to ensure that the configured account attributes are effective <civodul>what does not happen is removal of no-longer specified accounts <civodul>this is what davexunit was referring to <davexunit>I worry about cruft accruing on machines, as seen with puppet and co. <jpt4>Concerning unspecified accounts, where is root? Is there a %base-users? <davexunit>if I as the sysadmin must take care to remove the users manually, I hit scaling problems when I try to revoke a user's access from 100 servers. <davexunit>ideally, I'd like that to be a new generation of my GuixSD system. <davexunit>guix can't help with deleting home dirs in any sane way, but it could ensure that the user is no longer valid. <mark_weaver>jpt4: there's no %base-users. There's %root-account defined in gnu/system.scm and automatically added to the list of accounts provided by the user in 'operating-system-accounts', defined in the same file. <civodul>davexunit: i see, you're probably right <mark_weaver>jpt4: oh, it's only added if you didn't add a root account yourself. <mark_weaver>so actually, I think that's not bad. what do you think? <civodul>davexunit: would you like to file it on bug-guix? :-) <civodul>i'm not sure if there's an API to enumerate all the user accounuts <davexunit>civodul: trying to think ahead towards "GuixOps" :P <davexunit>because my plans are to manage large groups of machines with Guix. :) <mark_weaver>we might want to provide a mode that inhibits deletion of users/groups though <davexunit>in my head, I have a marketting line: "from development to production, with Guix!" <davexunit>'guix environment' is the first step for the development part <mark_weaver>davexunit: btw, if we do as you suggest, then I think we should take steps to *prevent* users from modifying /etc/{passwd,group,shadow,gshadow} in any other obvious way. <mark_weaver>because otherwise, people will run 'passwd' or add a user/group outside of guix, and be annoyed when guix undoes their work. <davexunit>mark_weaver: is being owned by root not enough? <davexunit>those files currently live outside of /gnu/store, yes? if we do what I propose, could they be immutable files in the store? <mark_weaver>davexunit: well, they are normally owned by root, and users are accustomed to having to be root to modify them. <civodul>mark_weaver: but we want to allow people to use 'passwd' <mark_weaver>yeah, I don't know how to implement what I'm suggesting. <mark_weaver>but it seems like people are likely to make that mistake and then scream at us when we undo their changes. <davexunit>if they use passwd, guix would indeed undo their work, but that is true for other things in the system. <davexunit>people experience this with puppet and co. already <mark_weaver>I would actually go so far as to say that our current behavior should be the default. <mark_weaver>and then to provide a mode that does the other thing <davexunit>ideally, I'd like /etc/passwd to be another immutable thing. <davexunit>I worry about the complexity of introducing 2 modes of operation for this, but perhaps it's the only way to satisfy everyone. <mark_weaver>davexunit: I agree that's preferable, I just want to prevent bad surprises and people screaming at us :) <mark_weaver>(which I think I might do if such a thing caught me by surprise) <davexunit>I don't like the idea of having undocumented users in the system. it guides people to creating unreproducable systems. <davexunit>is there a way to have /etc/passwd be immutable only *and* not surprise people? perhaps not. <mark_weaver>davexunit: there's a lot of other mutable state in /etc currently <mark_weaver>davexunit: for the ideal mostly-immutable system, but where you want a few things mutable like databases, it might be best to recreate your root partition from scratch everytime with 'guix system init', and then keep your explicitly mutable data on another partition. <mark_weaver>the mutable data could be put into the system with either symlinks or bind mounts to the mutable partition. <davexunit>to me, there's a distinction with something like a database. the creation of a database wouldn't be something you specified in your OS config. <davexunit>that's the kind of stateful stuff that guix need not bother with. <jpt4>Unless legacy unix is to be abandoned entirely in favor of GuixOS (as opposed to GS*Distribution*), the aesthetic is one of guix as a safe, immutable overlay manipulating or replicating the function of imperative primitives. <jpt4>Thus, the more functionality that is co-opted into the immutable sphere of control the better, as it disincentives system adminstration outside of it. <mark_weaver>I think different users will want different sets of things managed immutably. for example, most casual users probably want their network manager to remember wireless networks they've connected to. <mark_weaver>whereas for some other applications, you might want the wireless config to be entirely in the OS config file, and overwritten completely on every reconfigure. <jpt4>mark_weaver: Why is a record of observed networks not immutable? As a time series, its monotonic. Also, is not "overwritten completely" a slight exaggeration given that previous configs can be resumed? <jpt4>resumed -> selected at boot? <davexunit>that specific example seems like like something that is saved in a user's home dir. <mark_weaver>davexunit: mmm, it probably should be, but wicd doesn't work that way. <mark_weaver>(we should deprecate wicd btw, since it's no longer maintained) <jgrant>mark_weaver: Oh it isn't? It'd probably be realtively trivial to roll a interface for Wpa_supplicant and iw, really. <mark_weaver>jpt4: well, some people might want to declare the list of wireless networks to auto-connect to (and their authentication info) in the OS config, such that they could remove an item from that list and the next 'guix system reconfigure' would completely overwrite the wireless config, removing anything that had been added by convenient GUI wireless config tools. <davexunit>my rule of thumb seems to be: if it can be specificed in an OS config, it ought to be stateless. everything outside of that is stateful and guix will respect that. <mark_weaver>jpt4: but many users want to be able to use a network manager GUI to join a network without having to reconfigure their system. <davexunit>it's a shame that something like that would be a whole system setting, rather than a per-user one. <mark_weaver>davexunit: well, network settings are system-wide. consider multi-user systems. <mark_weaver>if two people are logged in at the same time, and network configuration is per-user, how do you handle that? <jpt4>mark_weaver: I see, though I wonder if guix has the concept of "live reconfiguration"? If kexec can swap kernels out from under the user, why would a guix-integrated wifi-menu not be modelled as the input to a new, transparent system reconfig? <mark_weaver>two people can be logged in to the console as well. sometimes two people share a computer, and some desktop environments support quick switching between them. <mark_weaver>(where there are actually two X server running simultanously) <mark_weaver>jpt4: 'guix system reconfigure' is live in the sense that /run/current-system is immediately swapped out (but not /run/booted-system) <mark_weaver>and normally, on a GuixSD system, /run/current-system/profile/bin is in PATH, ditto for many other environment variables. <civodul>eventually 'guix system reconfigure' will also (re)start services when doing that doesn't have any undesirable side effects <mark_weaver>jpt4: but I think that kexec can't do what you suggest <mark_weaver>but in the general case, you can switch to some other arbitrary kernel and migrate the data structures in a sane way. <mark_weaver>well, I'd be *extremely* surprised if anyone had gotten that to work for anything other than small patches. <jpt4>mark_weaver: For the specific case of a guix-wicd then, could not selecting a new network generate a new specification of the running system, to be reported as a previous revision at boot? <mark_weaver>it would require the kernel code to either cope with existing data structures from a different kernel, or the infrastructure to somehow convert those data structures on the fly. <mark_weaver>jpt4: you mean have it automatically edit your OS config file? <mark_weaver>(and then it would have to run 'guix system reconfigure' automatically, or something) <jpt4>mark_weaver: Rather, produce a new config.scm. <mark_weaver>jpt4: it amounts to editing it, because the new config.scm better be almost the same as I had it. <davexunit>jpt4: it couldn't do that reliably. it could create a new operating-system object, but it could never preserve the code as you wrote it. <mark_weaver>and then there's the question of what if you're not currently running the latest generation of your system. <davexunit>this isn't a 2 way street. a human writes the config and tells guix to apply it. <mark_weaver>what if you're currently booted into an older generation, which does not correspond to your OS config file. <jpt4>mark_wevaer: Currently, if I boot to an older system, do I not have an older /etc/config.scm? <mark_weaver>I would prefer a model where the user can choose to make wireless configuration a part of the mutable world, or to make it part of their OS config, but not both. <jpt4>Ah, so the system lineage is a chain, not a tree. <davexunit>you're booting an older system that corresponds to an operating-system object that was read from a previous version of your config.scm file. <mark_weaver>I could imagine implementing something analogous to emacs configure, which allows editing of a well-delineated part of .emacs <jpt4>davexunit: The object corresponds deterministically to an older config though, correct? <mark_weaver>but we'd better not do that without it being very obvious to the user what's happening, as in emacs. <mark_weaver>I don't want the network manager GUI to magically edit my config behind the scenes :) <mark_weaver>jpt4: the operating system object aims to be a pure function of the configuration file and the version of guix (e.g. git commit) <jpt4>mark_weaver: Indeed, absent a revision controlled tree of (config, OS) pairs, I rescind my previous remarks concerning the immutable potential of network connections. <mark_weaver>it's affected by any local changes you've made to your guix source tree, if you run guix out of the source tree (as I do) <davexunit>jpt4: I highly recommend keeping your configs in version control, but the state of your text files is not the concern of guix ;) <davexunit>I have 2 extra repos, one for configs, and one for extra packages. could probably roll it into one. <jpt4>davexunit: Urbit and guix/gsd are my two favorite systems programming projects, the first of which influenced my former comments. However, I recognize the difference in scope and application between the two, and thank you and mark_weaver for clarifying. <mark_weaver>jpt4: glad to have you here, your comments have been quite welcome <jgrant>Since we have more than one graphical session now, should we move away from slim-service or whatever adds windowsmaker? <Sleep_Walker>I was always wondering - what sort of pattern does `guix package -d' accept? <Sleep_Walker>I tried regexp, I tried shell pattern matching - none of it worked <Sleep_Walker>jgrant: slim is "Simple LogIn Manager", it is able to select window manager by your choice <jgrant>Sleep_Walker: I'm not sure what pulls it, but something pulls Windowsmaker in a simple install. <jpt4>jgrant:%windowmaker and %ratpoison are Scheme variables associated with slim-service, according to 6.2.7.3 <mark_weaver>jgrant: see %default-sessions in gnu/services/xorg.sc <jgrant>mark_weaver: Thanks for the pointer. *jgrant investigates a bit and sees why it's seemingly being called. <mark_weaver>jgrant: you can override the set of services supported by slim-service by adding the #:sessions keyword argument. *mark_weaver goes afk again for a while <jgrant>mark_weaver: Will it still download windowmaker though? <jxself>mark_weaver: But not the corresponding -libre version. <jxself>And lxo has taken off to give a talk at a conference so there may be a delay. <mark_weaver>jgrant: looks like you'll also need to pass #:auto-login-session to slim-service, because its default value refers to windowmaker.