Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 23, 2012, at 12:11 PM, Devin Teske wrote: On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: [snip] Also it said that my user add failed but it was actually added as uid 1005. I'm working on this one. I'm changing the routines to allow the UNIX pw(8) errors to filter through, rather than masking them with a static error on non-success. I overhauled the usermgmt module to rely entirely on pw(8). It should work a lot better now. I addressed all concerns in the rewrite which should be published soon in the up-coming 0.7.3 PORTVERSION. I added another user and it stated the uid 1005 when I was creating it but showed 1006 in the summary screen. It also said that adding the user failed. pw usernext is executed to get the next uid/gid pair that is available. It's possible a user was added in the process. I've not witnessed this, but will try to replicate. This race-condition was addressed and should no longer be possible (regardless of whether it was the root cause of the failure to add). Perhaps I used to short a password as there was no password field entered in /etc/master.passwd twat:*:1005:1005::1340540161:1340626570:twat:/home/twat:/bin/sh test1:*:1006:1006::1340454020:1340496000:test1:/home/test1:/bin/tcsh The password is only set (as a separate command) if the pw(8) useradd succeeded. I'm working on catching errors in edge-cases where we should proceed despite non-success. This too has been enhanced. When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. I filed PR docs/169354 against the passwd(5) manual. If nobody picks up the PR in a timely fashion, I'll pro-actively modify bsdconfig to follow what the man-page _should_ say versus what it _does_ say about how to treat the value of zero (the default). PR docs/169354 was closed after being patched by bjk@ (thx again bjk!) The upcoming release folds this change in to coincide with the updated manual. -- Thanks again for testing! Devin P.S. Keep an eye out for the next revision of this port for more testing. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 3:44 PM, Devin Teske wrote: On Jun 22, 2012, at 3:32 PM, Devin Teske wrote: On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. This was on-purpose because there is a discrepancy in passwd(5) manual regarding what a value of zero (0) means for these fields. From passwd(5): The change field is the number of seconds from the epoch, UTC, until the password for the account must be changed. This field may be left empty to turn off the password aging feature. Nowhere in the manual does it say that zero is a synonym to being left empty. And yet, this is how the system treats zero (was my complaint). The user root (and toor, and several other system users) come with a default value of zero for this field. If zero was treated according to the manual, then root would be disabled by default. But that's clearly not the case in a default installation which has a value of zero. So, when you're using bsdconfig to view an existing user that has a value of zero, you will notice that the default calendar date/time that is chosen corresponds to zero seconds from the epoch, UTC, despite the fact that I know (and you know) that zero is synonymous with NULL. So I'm a fan of updating the man page and when that is done, I am happy to change bsdconfig to treat zero as-such. But right now I wanted to stay true to the manual (which plainly states that any non-NULL value is treated as seconds from the epoch). In an effort to get the passwd(5) manual updated (pre-requisite to fixing the bsdconfig(8) functionality to coincide with the manual change), I've filed PR ports/169354. http://www.FreeBSD.org/cgi/query-pr.cgi?pr=169354 -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). I've made the necessary changes to support vlan0-vlan9 (though the system will only support up to vlan65534). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. If you're using em(4) device, try: sysctl dev.em.0.%desc Otherwise (for example), if using fxp(4), try: sysctl dev.fxp.0.%desc Or for your vlan: sysctl dev.vlan.16.%desc And try for your ipfw(4) interface: sysctl dev.ipfw.0.%desc Are each of those meaningful? NOTE: They aren't available unless you have the hardware -- so I can't (for example) try sysctl dev.fxp.0.%desc unless I have an fxp0 device displayed in ifconfig(8). That's driver-dependent. For example, lagg does not presents %desc nor ipfw0 and I suppose pretty many others do not. You could use %desc if it's present and fall back to internal static list otherwise. Ok, I've added that functionality, but … since neither lagg(4) nor ipfw(4) provide %desc MIB, … what should we provide as static fallbacks? Just something cosmetic but when I add a user when it comes to select the shell it does not have a title like: Select a shell I fixed this too. Also it said that my user add failed but it was actually added as uid 1005. I'm working on this one. I'm changing the routines to allow the UNIX pw(8) errors to filter through, rather than masking them with a static error on non-success. I added another user and it stated the uid 1005 when I was creating it but showed 1006 in the summary screen. It also said that adding the user failed. pw usernext is executed to get the next uid/gid pair that is available. It's possible a user was added in the process. I've not witnessed this, but will try to replicate. Perhaps I used to short a password as there was no password field entered in /etc/master.passwd twat:*:1005:1005::1340540161:1340626570:twat:/home/twat:/bin/sh test1:*:1006:1006::1340454020:1340496000:test1:/home/test1:/bin/tcsh The password is only set (as a separate command) if the pw(8) useradd succeeded. I'm working on catching errors in edge-cases where we should proceed despite non-success. When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. I filed PR docs/169354 against the passwd(5) manual. If nobody picks up the PR in a timely fashion, I'll pro-actively modify bsdconfig to follow what the man-page _should_ say versus what it _does_ say about how to treat the value of zero (the default). -- Thanks for testing!, Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
22.06.2012 10:50, Ron McDowell пишет: Again, thank you very much for testing this new software. P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. I'm one of the coauthors of this code, and I am here on -stable. As stated, this port will only run on 9.0-RELEASE and later. Please give it a try! Thanks! I've tried it on installed 9.0-STABLE system. 1. At the moment, the documentation does not install: Could not install package en-freebsd-doc (pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/en-freebsd-doc.tbz' by URL) 2. For system running single gmirror gm0 consisting of 2 whole disks ada0 and ada1, 'Label allocated disk partitions' offers only ada0 and ada1 for disklabel editor and not gm0. And disklabel editor shows empty list of partitions. 3. Similar for FDISK Partition Editor (ada0/ada1 and not gm0 for choise), but Partition Editor presents whole disk space as 'unused' Note that current SATA disk prices and quality offers no choice for servers other that some kind of RAID. 4. Networking Devices configuration presents lagg0 device as unknown network interface type. It should provide descriptive string like 'Link aggregation/failover'. 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. 6. Same for ipfw0 pseudo-interface. 7. Networking Devices configuration does not allow to configure any interface while there are mounted NFS volumes. Should present a warning only, not disallow the operation. For example, it should be possible to configure new vlan interface while NFS mount uses another vlan. 8. In DNS Nameserver Configuration, it's not clear that one, in fact, can remove unneeded DNS server through two-step procedure - first try to edit, then clear the address. It should be more obvious at first. That's enough for this time :-) Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 12:07 AM, Eugene Grosbein wrote: 22.06.2012 10:50, Ron McDowell пишет: Again, thank you very much for testing this new software. P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. I'm one of the coauthors of this code, and I am here on -stable. As stated, this port will only run on 9.0-RELEASE and later. Please give it a try! Thanks! I've tried it on installed 9.0-STABLE system. First, thank you for testing! 1. At the moment, the documentation does not install: Could not install package en-freebsd-doc (pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/en-freebsd-doc.tbz' by URL) Ok. Thx. A PR should be filed against bsdinstall (since bsdconfig is simply linking to bsdinstall docsinstall for that menu item and is not actually responsible for the bug). 2. For system running single gmirror gm0 consisting of 2 whole disks ada0 and ada1, 'Label allocated disk partitions' offers only ada0 and ada1 for disklabel editor and not gm0. And disklabel editor shows empty list of partitions. Ok, Thx. This too is not part of bsdconfig, but is linked to sade(8). NOTE: Documentation Installation and Disk Partition/Label are the only two modules that are pointed to other tools (the former linked to bsdinstall docsinstall and the latter linked to sade). The goal for this is to replace sade (which is not geom compatible) with a new tool. This is on the community's to-do list. 3. Similar for FDISK Partition Editor (ada0/ada1 and not gm0 for choise), but Partition Editor presents whole disk space as 'unused' Note that current SATA disk prices and quality offers no choice for servers other that some kind of RAID. Again, this is because sade(8) is not geom compatible. 4. Networking Devices configuration presents lagg0 device as unknown network interface type. It should provide descriptive string like 'Link aggregation/failover'. It's on my to-do list to change the way descriptions are calculated. Currently, I've got a static hard-coded list of descriptions. Someone recommended that there was a way to get this information from sysctl. 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. 7. Networking Devices configuration does not allow to configure any interface while there are mounted NFS volumes. Should present a warning only, not disallow the operation. Did I completely disallow it? I'll have to re-check -- I thought that I had made it so that you could view/edit the configuration but that the warning says that changes will not become effective until you either reboot or visit the menu again when no NFS mounts are active. For example, it should be possible to configure new vlan interface while NFS mount uses another clan. Do you know of a handy way of determining which NFS mount is using which network interface? And further, is there a handy way of traversing the route path to determine that one interface isn't required as an intermediary transit device? (meaning: can one truly ever know that making a new configuration active on any interface could not potentially drop your entire machine from the net with hung NFS mounts?) Many months of testing in the lab produced no less than 6 edge-cases where -- if a network link or route is modified when NFS mounts are active -- the machine can enter an unstable/unusable state. So we decided to err on the side of caution when it came to allowing settings to be made-active when NFS mounts are active. I'm not against improving the code, but I'm wondering if it wouldn't be safer to stick to disallowing any/all changes from being made-active (while allowing viewing/editing without making-active) when NFS mounts are active. NOTE: There are other safe-guards too. For example, if you're logged in via SSH and using X11 forwarding while passing the -X flag (to use Xdialog(1)), you are disallowed from making a new hostname active (you can change the hostname, but not make it active) because that would cause the very next iteration of Xdialog(1) to fail due to a surreptitious X authority revocation based on the hostname-change in mid-session. 8. In DNS Nameserver Configuration, it's not clear that one, in fact, can remove unneeded DNS server
Re: [CFT] Need Testers for: sysutils/bsdconfig
22.06.2012 14:37, Devin Teske пишет: 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. 7. Networking Devices configuration does not allow to configure any interface while there are mounted NFS volumes. Should present a warning only, not disallow the operation. Did I completely disallow it? Yes. I'll have to re-check -- I thought that I had made it so that you could view/edit the configuration but that the warning says that changes will not become effective until you either reboot or visit the menu again when no NFS mounts are active. For example, it should be possible to configure new vlan interface while NFS mount uses another clan. Do you know of a handy way of determining which NFS mount is using which network interface? And further, is there a handy way of traversing the route path to determine that one interface isn't required as an intermediary transit device? (meaning: can one truly ever know that making a new configuration active on any interface could not potentially drop your entire machine from the net with hung NFS mounts?) Many months of testing in the lab produced no less than 6 edge-cases where -- if a network link or route is modified when NFS mounts are active -- the machine can enter an unstable/unusable state. So we decided to err on the side of caution when it came to allowing settings to be made-active when NFS mounts are active. I'm not against improving the code, but I'm wondering if it wouldn't be safer to stick to disallowing any/all changes from being made-active (while allowing viewing/editing without making-active) when NFS mounts are active. NOTE: There are other safe-guards too. For example, if you're logged in via SSH and using X11 forwarding while passing the -X flag (to use Xdialog(1)), you are disallowed from making a new hostname active (you can change the hostname, but not make it active) because that would cause the very next iteration of Xdialog(1) to fail due to a surreptitious X authority revocation based on the hostname-change in mid-session. I'm sure that bsdconfig should emit warnings only but not disallow root to make any needed changes. NFS may use completly unrelated routes/interfaces, X11 may be user over network without ssh -X etc. It's pretty annoying for administrator to fight with tools thinking they know better what root should do. 8. In DNS Nameserver Configuration, it's not clear that one, in fact, can remove unneeded DNS server through two-step procedure - first try to edit, then clear the address. It should be more obvious at first. Can you have a look at bsdconfig startup_rcconf and see if that's a better way to go about the deletion-process? Or perhaps you're just advocating a helpful message in the text above the menu list that explains how to delete the item? (least amount of work) Again, just a message. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 12:53 AM, Eugene Grosbein wrote: 22.06.2012 14:37, Devin Teske пишет: 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. If you're using em(4) device, try: sysctl dev.em.0.%desc Otherwise (for example), if using fxp(4), try: sysctl dev.fxp.0.%desc Or for your vlan: sysctl dev.vlan.16.%desc And try for your ipfw(4) interface: sysctl dev.ipfw.0.%desc Are each of those meaningful? NOTE: They aren't available unless you have the hardware -- so I can't (for example) try sysctl dev.fxp.0.%desc unless I have an fxp0 device displayed in ifconfig(8). 7. Networking Devices configuration does not allow to configure any interface while there are mounted NFS volumes. Should present a warning only, not disallow the operation. Did I completely disallow it? Yes. I'll have to re-check -- I thought that I had made it so that you could view/edit the configuration but that the warning says that changes will not become effective until you either reboot or visit the menu again when no NFS mounts are active. For example, it should be possible to configure new vlan interface while NFS mount uses another clan. Do you know of a handy way of determining which NFS mount is using which network interface? And further, is there a handy way of traversing the route path to determine that one interface isn't required as an intermediary transit device? (meaning: can one truly ever know that making a new configuration active on any interface could not potentially drop your entire machine from the net with hung NFS mounts?) Many months of testing in the lab produced no less than 6 edge-cases where -- if a network link or route is modified when NFS mounts are active -- the machine can enter an unstable/unusable state. So we decided to err on the side of caution when it came to allowing settings to be made-active when NFS mounts are active. I'm not against improving the code, but I'm wondering if it wouldn't be safer to stick to disallowing any/all changes from being made-active (while allowing viewing/editing without making-active) when NFS mounts are active. NOTE: There are other safe-guards too. For example, if you're logged in via SSH and using X11 forwarding while passing the -X flag (to use Xdialog(1)), you are disallowed from making a new hostname active (you can change the hostname, but not make it active) because that would cause the very next iteration of Xdialog(1) to fail due to a surreptitious X authority revocation based on the hostname-change in mid-session. I'm sure that bsdconfig should emit warnings only but not disallow root to make any needed changes. I'm inclined to agree. FreeBSD should not prevent you from being stupid (as someone once told me). I should change the errors to warnings and allow the user to [potentially] hose their connection given ample warning/chance-to-back-out. NFS may use completly unrelated routes/interfaces, X11 may be user over network without ssh -X etc. Got that one covered actually -- you can tell when a user is using X11 forwarding versus X11 local. It's pretty annoying for administrator to fight with tools thinking they know better what root should do. 8. In DNS Nameserver Configuration, it's not clear that one, in fact, can remove unneeded DNS server through two-step procedure - first try to edit, then clear the address. It should be more obvious at first. Can you have a look at bsdconfig startup_rcconf and see if that's a better way to go about the deletion-process? Or perhaps you're just advocating a helpful message in the text above the menu list that explains how to delete the item? (least amount of work) Again, just a message. Ok, cool. Thanks again, -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
Re: [CFT] Need Testers for: sysutils/bsdconfig
22.06.2012 15:39, Devin Teske wrote: 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. If you're using em(4) device, try: sysctl dev.em.0.%desc Otherwise (for example), if using fxp(4), try: sysctl dev.fxp.0.%desc Or for your vlan: sysctl dev.vlan.16.%desc And try for your ipfw(4) interface: sysctl dev.ipfw.0.%desc Are each of those meaningful? NOTE: They aren't available unless you have the hardware -- so I can't (for example) try sysctl dev.fxp.0.%desc unless I have an fxp0 device displayed in ifconfig(8). That's driver-dependent. For example, lagg does not presents %desc nor ipfw0 and I suppose pretty many others do not. You could use %desc if it's present and fall back to internal static list otherwise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: [CFT] Need Testers for: sysutils/bsdconfig
5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'. It should work same way for vlan1-vlan4095 interfaces at least. I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number). 6. Same for ipfw0 pseudo-interface. Curious what sysctl says about it. I do not know what sysctl subtree do you refer to. If you're using em(4) device, try: sysctl dev.em.0.%desc Otherwise (for example), if using fxp(4), try: sysctl dev.fxp.0.%desc Or for your vlan: sysctl dev.vlan.16.%desc And try for your ipfw(4) interface: sysctl dev.ipfw.0.%desc Are each of those meaningful? NOTE: They aren't available unless you have the hardware -- so I can't (for example) try sysctl dev.fxp.0.%desc unless I have an fxp0 device displayed in ifconfig(8). That's driver-dependent. For example, lagg does not presents %desc nor ipfw0 and I suppose pretty many others do not. You could use %desc if it's present and fall back to internal static list otherwise. Just something cosmetic but when I add a user when it comes to select the shell it does not have a title like: Select a shell Also it said that my user add failed but it was actually added as uid 1005. I added another user and it stated the uid 1005 when I was creating it but showed 1006 in the summary screen. It also said that adding the user failed. Perhaps I used to short a password as there was no password field entered in /etc/master.passwd twat:*:1005:1005::1340540161:1340626570:twat:/home/twat:/bin/sh test1:*:1006:1006::1340454020:1340496000:test1:/home/test1:/bin/tcsh When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. //Clay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. This was on-purpose because there is a discrepancy in passwd(5) manual regarding what a value of zero (0) means for these fields. From passwd(5): The change field is the number of seconds from the epoch, UTC, until the password for the account must be changed. This field may be left empty to turn off the password aging feature. Nowhere in the manual does it say that zero is a synonym to being left empty. So I can think of one of two solutions: Update the manual to say that 0 is the same as being left empty or Change the behavior to treat zero as [zero] seconds from the epoch. Currently, bsdconfig treats zero as the latter, not the former -- until such discrepancy can be resolved. NOTE: It should also be noted that Linux and FreeBSD when pointed at the same LDAP server have disagreements between the value of this field and the best solution in this situation is to remove the field in question (e.g., shadowExpire, shadowMax, etc.). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On Jun 22, 2012, at 3:32 PM, Devin Teske wrote: On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote: When selecting user account expiry the calendar starts at 1 January 1970. I understand that this is when Unix time started but it would be nice for it to start from the current date. This was on-purpose because there is a discrepancy in passwd(5) manual regarding what a value of zero (0) means for these fields. From passwd(5): The change field is the number of seconds from the epoch, UTC, until the password for the account must be changed. This field may be left empty to turn off the password aging feature. Nowhere in the manual does it say that zero is a synonym to being left empty. And yet, this is how the system treats zero (was my complaint). The user root (and toor, and several other system users) come with a default value of zero for this field. If zero was treated according to the manual, then root would be disabled by default. But that's clearly not the case in a default installation which has a value of zero. So, when you're using bsdconfig to view an existing user that has a value of zero, you will notice that the default calendar date/time that is chosen corresponds to zero seconds from the epoch, UTC, despite the fact that I know (and you know) that zero is synonymous with NULL. So I'm a fan of updating the man page and when that is done, I am happy to change bsdconfig to treat zero as-such. But right now I wanted to stay true to the manual (which plainly states that any non-NULL value is treated as seconds from the epoch). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[CFT] Need Testers for: sysutils/bsdconfig
Hi everybody, I've published a new port (sysutils/bsdconfig) so that we can get some testing on the replacement for sysinstall's [post-installation] Configure menu. We're on a tight schedule, so if you have the time and/or energy your timely efforts will be GREATLY appreciated in helping to get this software tested prior to the 9.1-R code freeze. Please welcome bsdconfig (port pkg-descr below): bsdconfig is a robust utility for configuring/managing various aspects of the FreeBSD Operating System. Feature-highlights include (but are not limited to): - Modular, stable, efficient and i18n-compatible. - Easily maintained/extendable sh(1) source/syntax. - Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog). - rc.conf(5) configuration/management based on sysutils/sysrc - Timezone configuration based on sysutils/tzdialog - Networking management based on sysutils/host-setup WWW: http://druidbsd.sourceforge.net/ Again, thank you very much for testing this new software. -- Devin P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
Sorry, forgot to mention… The port will only install/work on 9.0 or higher. Testing needed on FreeBSD 9.0-R (or higher) and/or PC-BSD 9.0-R (or higher). -- Devin On Jun 21, 2012, at 3:32 PM, Devin Teske wrote: Hi everybody, I've published a new port (sysutils/bsdconfig) so that we can get some testing on the replacement for sysinstall's [post-installation] Configure menu. We're on a tight schedule, so if you have the time and/or energy your timely efforts will be GREATLY appreciated in helping to get this software tested prior to the 9.1-R code freeze. Please welcome bsdconfig (port pkg-descr below): bsdconfig is a robust utility for configuring/managing various aspects of the FreeBSD Operating System. Feature-highlights include (but are not limited to): - Modular, stable, efficient and i18n-compatible. - Easily maintained/extendable sh(1) source/syntax. - Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog). - rc.conf(5) configuration/management based on sysutils/sysrc - Timezone configuration based on sysutils/tzdialog - Networking management based on sysutils/host-setup WWW: http://druidbsd.sourceforge.net/ Again, thank you very much for testing this new software. -- Devin P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] Need Testers for: sysutils/bsdconfig
On 6/21/12 5:32 PM, Devin Teske wrote: Hi everybody, I've published a new port (sysutils/bsdconfig) so that we can get some testing on the replacement for sysinstall's [post-installation] Configure menu. We're on a tight schedule, so if you have the time and/or energy your timely efforts will be GREATLY appreciated in helping to get this software tested prior to the 9.1-R code freeze. Please welcome bsdconfig (port pkg-descr below): bsdconfig is a robust utility for configuring/managing various aspects of the FreeBSD Operating System. Feature-highlights include (but are not limited to): - Modular, stable, efficient and i18n-compatible. - Easily maintained/extendable sh(1) source/syntax. - Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog). - rc.conf(5) configuration/management based on sysutils/sysrc - Timezone configuration based on sysutils/tzdialog - Networking management based on sysutils/host-setup WWW: http://druidbsd.sourceforge.net/ Again, thank you very much for testing this new software. P.S. Due to the large codebase comprising bsdconfig, ample precautions should be taken. I've not noticed any negative behavior in months of usage, but just be warned. P.P.S. I don't think on subscribed to -stable@, so include me in your replies. I'm one of the coauthors of this code, and I am here on -stable. As stated, this port will only run on 9.0-RELEASE and later. Please give it a try! Thanks! -- Ron McDowell San Antonio TX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
