Re: SU+J Lost files after a power failure
David Demelier wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. Any ideas? Should I open a PR? Not sure there is enough to go on for a PR, but something is weird. Friday morning our power went down at home for about three hours after I had already left for work. When I came home I found the router/gateway box was OK. It is still with the old DOS mbr and disklabel scheme, with softupdates, and is a pair of disks gmirrored. The other box is my first foray into the land of GPT, along with SU+J. It was sitting at the 'couldn't mount... Press return for /bin/sh' line. There was an error indicating that replaying one or more journals had failed. I was able to successfully fsck all the other partitions (besides /), then rebooted and system came back up OK. Both of these machines were recently updated to 9.2 Release from 9.1. It has been approximately 9 months, or so, since I last had a power outage like this one. Back then they were still 8.3 I think, did not have SU+J and recovered just fine on their own. This error about the replay of the journal(s) failing is somewhat disconcerting. Beyond that, however, I do not have any other details or data. Nothing to flesh out a PR, but thought I'd mention what I saw in conjunction with your experience. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
Michael Powell wrote: [snip] The other box is my first foray into the land of GPT, along with SU+J. It was sitting at the 'couldn't mount... Press return for /bin/sh' line. There was an error indicating that replaying one or more journals had failed. I was able to successfully fsck all the other partitions (besides /), then rebooted and system came back up OK. Meant to include also that I booted from a CD with wddiags and ran the Quick test and it found no errors on the disk. [snip] -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, 14 Oct 2013 05:02:22 -0400 Michael Powell wrote: David Demelier wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. The journalling in SU+J has nothing to do with data integrity. When the system isn't shut-down cleanly, soft-updates are supposed to leave the filesystem in a self-consistent state, except that it may lose track of some freed disk space. The journal allows that space to be recovered without the lengthy background fsck that used to cripple performance. If you are having problems with data integrity you might try gjournal or zfs instead. If you look back at the lists before these were added there was a lot of suspicion about soft-updates and background checks. Some of the problems were explained by some (mostly desktop) drives incorrecty reporting what has been commited to disk - I don't know whether this is still the case. This error about the replay of the journal(s) failing is somewhat disconcerting. I think this is probably a good thing. With background checks you would (if you were looking) occasionally see unexpected soft-update inconsistency during the background check, which would lead to a foreground check on the next boot. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 14.10.2013 14:39, RW wrote: On Mon, 14 Oct 2013 05:02:22 -0400 Michael Powell wrote: David Demelier wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. The journalling in SU+J has nothing to do with data integrity. When the system isn't shut-down cleanly, soft-updates are supposed to leave the filesystem in a self-consistent state, except that it may lose track of some freed disk space. The journal allows that space to be recovered without the lengthy background fsck that used to cripple performance. If you are having problems with data integrity you might try gjournal or zfs instead. Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? On GNU/Linux, on Windows you will not require anything else to recover your data. I don't want to tweak the filesystem or use something different that the default, as it is the default it's the *warranty* that it is the correct way to protect data for new FreeBSD user's installations IMHO. If you look back at the lists before these were added there was a lot of suspicion about soft-updates and background checks. Some of the problems were explained by some (mostly desktop) drives incorrecty reporting what has been commited to disk - I don't know whether this is still the case. This error about the replay of the journal(s) failing is somewhat disconcerting. I think this is probably a good thing. With background checks you would (if you were looking) occasionally see unexpected soft-update inconsistency during the background check, which would lead to a foreground check on the next boot. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 6:34 PM, David Demelier demelier.da...@gmail.com wrote: Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? On GNU/Linux, on Windows you will not require anything else to recover your data. I don't want to tweak the filesystem or use something different that the default, as it is the default it's the *warranty* that it is the correct way to protect data for new FreeBSD user's installations IMHO. Agree :-) SU+J also seems to cause problems on SSD drives: http://lists.freebsd.org/pipermail/freebsd-fs/2013-February/016420.html -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 11:34 AM, David Demelier demelier.da...@gmail.comwrote: Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? As already stated, those measures are to preserve fs integrity eg meta data is in sync. It doesn't ensure that all the outstanding writes are committed to disk in the event of a power outage. On GNU/Linux, on Windows you will not require anything else to recover your data. This is complete garbage when using default settings as you imply below. The default for ext3 on basically every distro still using ext3 is an ordered journal and don't even get started on ext4. NTFS by default can/will also lose data on a power outage. I don't want to tweak the filesystem or use something different that the default, as it is the default it's the *warranty* that it is the correct way to protect data for new FreeBSD user's installations IMHO. There is no *warranty* as explicitly stated in http://www.freebsd.org/copyright/freebsd-license.html The behavior you wish would slow down disk writes by an order of magnitude and is already available to users willing to use non-default settings. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 6:47 PM, Adam Vande More amvandem...@gmail.com wrote: On Mon, Oct 14, 2013 at 11:34 AM, David Demelier demelier.da...@gmail.comwrote: Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? As already stated, those measures are to preserve fs integrity eg meta data is in sync. It doesn't ensure that all the outstanding writes are committed to disk in the event of a power outage. Then why random files gets damaged as well even they are not accessed/written on power loss? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 11:50 AM, CeDeROM cede...@tlen.pl wrote: Then why random files gets damaged as well even they are not accessed/written on power loss? :-) Prove they weren't. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 6:56 PM, Adam Vande More amvandem...@gmail.com wrote: On Mon, Oct 14, 2013 at 11:50 AM, CeDeROM cede...@tlen.pl wrote: Then why random files gets damaged as well even they are not accessed/written on power loss? :-) Prove they weren't. Hmm, maybe /etc/pwd.db as David mentioned? This is updated on password change, which does not happen all the time.. so why it was damaged when no write occured..? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 10/14/2013 12:50 PM, CeDeROM wrote: On Mon, Oct 14, 2013 at 6:47 PM, Adam Vande More amvandem...@gmail.com wrote: On Mon, Oct 14, 2013 at 11:34 AM, David Demelier demelier.da...@gmail.comwrote: Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? As already stated, those measures are to preserve fs integrity eg meta data is in sync. It doesn't ensure that all the outstanding writes are committed to disk in the event of a power outage. Then why random files gets damaged as well even they are not accessed/written on power loss? :-) Random files can be affected because the sectors of the hard disk containing the directory entries for those files, not the file data itself, may be damaged (ie: the directory was in the process of being written OR the pointer to that SECTOR was in the process of being written). It doesn't mean a file was in active use, just that a chunk of the disk with data relevant to that file was. Keep in mind, one sector of disk may have data for a dozen files in it (or more). Damage doesn't have to occur because a given file was in use at the time of a crash. If your power grid is prone to failures or blips, I strongly suggest investing in a UPS. Brad ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 7:09 PM, Brad Mettee bmet...@pchotshots.com wrote: On 10/14/2013 12:50 PM, CeDeROM wrote: Then why random files gets damaged as well even they are not accessed/written on power loss? :-) Random files can be affected because the sectors of the hard disk containing the directory entries for those files, not the file data itself, may be damaged (ie: the directory was in the process of being written OR the pointer to that SECTOR was in the process of being written). It doesn't mean a file was in active use, just that a chunk of the disk with data relevant to that file was. Keep in mind, one sector of disk may have data for a dozen files in it (or more). Damage doesn't have to occur because a given file was in use at the time of a crash. Isn't there Journal to prevent and reverse such damage? If your power grid is prone to failures or blips, I strongly suggest investing in a UPS. I have UPS in my desktop and also I am working on a laptop, so the power supply is not the only possible cause of system crash.. this may be faulty driver, hardware failure, kernel panic, etc. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 10/14/2013 6:16 PM, CeDeROM wrote: Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. For ext3, https://www.kernel.org/doc/Documentation/filesystems/ext3.txt explains the different modes, with 'ordered' being default: Data Mode - There are 3 different data modes: * writeback mode In data=writeback mode, ext3 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext3 performance. * ordered mode In data=ordered mode, ext3 only officially journals metadata, but it logically groups metadata and data blocks into a single unit called a transaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode. * journal mode data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it outperforms all other modes. -- Bruce Cran ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, 14 Oct 2013 18:34:36 +0200 David Demelier wrote: On 14.10.2013 14:39, RW wrote: If you are having problems with data integrity you might try gjournal or zfs instead. Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? SU+J isn't a journalled filesytem, it's a filesystem with soft-updates that journals information about free space so it can be recovered without having to go through the whole filesystem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 7:54 PM, Bruce Cran br...@cran.org.uk wrote: On 10/14/2013 6:16 PM, CeDeROM wrote: Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? Or to do a filesystem check after crash..? Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? That would assume disabling journal and soft updates journaling I guess..? What would be the best option for best data integrity in case of crash? That would be helpful for development systems I guess :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 10/14/2013 7:33 PM, CeDeROM wrote: Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? Or to do a filesystem check after crash..? Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? That would assume disabling journal and soft updates journaling I guess..? What would be the best option for best data integrity in case of crash? That would be helpful for development systems I guess :-) As I understand it UFS+J gives the same reliability as UFS with a normal fsck after a crash, so on a development system the only ways to improve the situation would be to mount with the 'sync' option, disable write caching on the disk or to switch to a different filesystem like ZFS. -- Bruce Cran ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 1:33 PM, CeDeROM cede...@tlen.pl wrote: Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? Please explain the logic in which this helps anything. Or to do a filesystem check after crash..? Already standard behavior as implicitly seen in this thread. Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? No and any fs that requires such a system is broken by design. That would assume disabling journal and soft updates journaling I guess..? What would be the best option for best data integrity in case of crash? mount -o sync or use ZFS. Both require hardware that correctly report success to fsync. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, Oct 14, 2013 at 1:43 PM, Adam Vande More amvandem...@gmail.comwrote: mount -o sync should be mount sync -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Oct 14, 2013, at 11:33 AM, CeDeROM cede...@tlen.pl wrote: On Mon, Oct 14, 2013 at 7:54 PM, Bruce Cran br...@cran.org.uk wrote: On 10/14/2013 6:16 PM, CeDeROM wrote: Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? You shouldn't ever need to recheck the filesystem if it was shutdown cleanly. However, it doesn't hurt to fire off an fsck once a year or so just to look for any unexpected issues. Or to do a filesystem check after crash..? Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, but sometimes that doesn't restore consistency, in which case it usually fires off a background fsck rather than the foreground fsck. Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? That would assume disabling journal and soft updates journaling I guess..? /etc/rc.conf should support something like the following to do what you ask: fsck_y_enable=YES background_fsck=NO force_fsck=YES What would be the best option for best data integrity in case of crash? That would be helpful for development systems I guess :-) Well, you can use mount -o sync and disable write caching via hw.ata.wc=0 or similar depending on what kind of drives you use. This will cause a massive loss of write performance, but will greatly improve reliability-- i.e. fsync() and such are not as likely to lie about whether bits have made it to disk, even in the face of hardware which lies about ATA_FLUSHCACHE (or SCSI SYNCHRONIZE CACHE, etc). Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
Thank you all for good hints! This will come handy! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, 14 Oct 2013, Bruce Cran wrote: On 10/14/2013 6:16 PM, CeDeROM wrote: Isn't there Journal to prevent and reverse such damage? Unlike other journaling filesystems, UFS+J only protects the metadata, not the data itself - i.e. I think it ensures you won't have to run a manual fsck, but just like plain old UFS files may be truncated as the journal is replayed. This discussion skirts the critical issue - are files that are not open for writing endangered? No description of the uses of journaling can be considered informative if it doesn't address that explicitly. As a naive user I have always assumed that once closed, a file was invulnerable to improper shutdowns, but this discussion shakes that belief. I expect the answer may be different for SSD and spinning disks. dan feenberg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, 14 Oct 2013 11:48:18 -0700 Charles Swiger wrote: Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. Journalling removes the need for the background fsck which only recovers lost space. With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, My understanding is that the journal does nothing to restore the filesystem other than keep track of orphaned memory. In all other respect it's the job of soft-updates to keep the filesystem in an OK state. When it doesn't you need a foreground check. but sometimes that doesn't restore consistency, in which case it usually fires off a background fsck rather than the foreground fsck. I think if the journal fails, you would really need to run at least a foreground preen, maybe a full fsck. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
Charles Swiger wrote: [snip] Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, but sometimes that doesn't restore consistency, in which case it usually fires off a background fsck rather than the foreground fsck. In my case the journal replay failed, with an error to that effect. All partitions other than / failed to mount and after hitting enter at the .../bin/sh prompt performed manual fsck on all of them, which found and fixed some stuff. Then shutdown -r and everything came up fine (clean) afterwards. Net result was no data loss for me. [snip] -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Mon, 14 Oct 2013 11:48:18 -0700 Charles Swiger wrote: fsck_y_enable=YES One of the most annoying things about SU+J is that fsck asks if you want to use the journal. So fsck -y wont do a proper check unless the journal replay fails. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 14.10.2013 20:08, RW wrote: On Mon, 14 Oct 2013 18:34:36 +0200 David Demelier wrote: On 14.10.2013 14:39, RW wrote: If you are having problems with data integrity you might try gjournal or zfs instead. Why? SU+J is enabled by default. Isn't the purpose of a journaled file system to ensure that any bad shutdown will protect data? SU+J isn't a journalled filesytem, it's a filesystem with soft-updates that journals information about free space so it can be recovered without having to go through the whole filesystem. Okay, but why the fsck didn't run by itself to detect that the journal didn't replayed correctly (if I understanding well) to correct the issues? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 14.10.2013 18:47, Adam Vande More wrote: There is no *warranty* as explicitly stated in http://www.freebsd.org/copyright/freebsd-license.html Aha, please don't play on words ;-). I think you understood I was speaking about the filesystem state not a lawyer issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 14.10.2013 20:43, Adam Vande More wrote: On Mon, Oct 14, 2013 at 1:33 PM, CeDeROM cede...@tlen.pl mailto:cede...@tlen.pl wrote: Thank you for explaining :-) So it looks that it would be sensible to force filesystem check every n-th mount..? Please explain the logic in which this helps anything. Or to do a filesystem check after crash..? Already standard behavior as implicitly seen in this thread. Are there any flags like that to mark filesystem unclean and to force fsck after n-th mount? No and any fs that requires such a system is broken by design. That would assume disabling journal and soft updates journaling I guess..? What would be the best option for best data integrity in case of crash? mount -o sync or use ZFS. Both require hardware that correctly report success to fsync. I personnally love ZFS and use it massively on my server, but for a desktop I think this is a real overkill. Also I don't have so much RAM to waste for that. I think UFS is enough, however as a modern operating system I don't expect any data corruption by default using SU+J. The filesystem domain is not a thing I really know deeply, so thanks for all you explanation. PS: the power failure is not the only way that does not shutdown cleanly the system. There are kernel panics, crash and such of course. Those which appears sometimes too. Regards, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
Hi-- On Oct 14, 2013, at 11:51 AM, Daniel Feenberg feenb...@nber.org wrote: This discussion skirts the critical issue - are files that are not open for writing endangered? No description of the uses of journaling can be considered informative if it doesn't address that explicitly. As a naive user I have always assumed that once closed, a file was invulnerable to improper shutdowns, but this discussion shakes that belief. Well, it's good to be a little paranoid if the data matters. :-) First, unless you call fsync() before close() and your OS and/or drive hardware isn't being deceptive when fsync() returns about whether the bits have made it to permanent storage, then you might be surprised at just how long the unwritten buffers containing the last updates to the file data take to get properly flushed to disk. I expect the answer may be different for SSD and spinning disks. Second, this is an excellent point: however, it also applies to anything where the actual hardware block size does not match the device blocksize that the filesystem thinks it has-- so new 4K sector rotational disks also have some risk. The basic issue with SSDs is that you (or the drive firmware, more precisely) need to read in an entire hardware sector, update the portion with changes in cache memory, do a bulk-erase of that block, and then scribble that back out. Good drive firmware actually writes out to a different block than the original for wear-leveling purposes and only updates the flash translation layer once the new version of that block is written. That makes the drive mostly immune to major data integrity issues even if powered off in the middle of the process. Less-than-good firmware, aka buggy firmware, can lead from power-failure to data loss of files which were not being modified at the time. And may you possess recent working backups if the FTL somehow ever gets confused! Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On Oct 14, 2013, at 12:41 PM, RW rwmailli...@googlemail.com wrote: On Mon, 14 Oct 2013 11:48:18 -0700 Charles Swiger wrote: Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. Journalling removes the need for the background fsck which only recovers lost space. That and inode link changes (ie, adding or removing files from a directory). With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, My understanding is that the journal does nothing to restore the filesystem other than keep track of orphaned memory. In all other respect it's the job of soft-updates to keep the filesystem in an OK state. Yes, SU is supposed to reorder filesystem operations to provide some level of ACID transaction semantics-- and the journal helps that by avoiding the need for bgfsck. When it doesn't you need a foreground check. but sometimes that doesn't restore consistency, in which case it usually fires off a background fsck rather than the foreground fsck. I think if the journal fails, you would really need to run at least a foreground preen, maybe a full fsck. Yes. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
SU+J Lost files after a power failure
Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. Any ideas? Should I open a PR? Regards, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 13 Oct 2013 11:30, David Demelier demelier.da...@gmail.com wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. Any ideas? Should I open a PR I had similar issues somewhere around 9.0 - although journal check was fine running fsck revealed filesystem inconsistency. I have reported this on the list, but it seemed unnoticed..? For me this is serious issue as well, if you make PR I will give +1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 13.10.2013 12:16, CeDeROM wrote: On 13 Oct 2013 11:30, David Demelier demelier.da...@gmail.com mailto:demelier.da...@gmail.com wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. Any ideas? Should I open a PR I had similar issues somewhere around 9.0 - although journal check was fine running fsck revealed filesystem inconsistency. I have reported this on the list, but it seemed unnoticed..? For me this is serious issue as well, if you make PR I will give +1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Yes, I've also ran fsck in single user mode after and lot of incorrect things were corrected, I wait a bit for answers (if any) before sending a PR. Cheers, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU+J Lost files after a power failure
On 13.10.2013 12:16, CeDeROM wrote: On 13 Oct 2013 11:30, David Demelier demelier.da...@gmail.com mailto:demelier.da...@gmail.com wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the password database with a live cd but I'm afraid that more files had disappeared somewhere else... I think this is a serious issue, the journal should not truncate files, so something should have gone wrong somewhere.. Any ideas? Should I open a PR I had similar issues somewhere around 9.0 - although journal check was fine running fsck revealed filesystem inconsistency. I have reported this on the list, but it seemed unnoticed..? For me this is serious issue as well, if you make PR I will give +1 :-) CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Yes, I've also ran fsck in single user mode after and lot of incorrect things were corrected, I wait a bit for answers (if any) before sending a PR. Running fsck in single-user mode may not be sufficient. You may need to run fsck_ffs from a USB-stick installation or live CD. I remember reviving a FreeBSD partition that way, normal root partition not mounted. I once revived a FreeBSD partition with fsck_ffs from a USB-stick installation of NetBSD 5.1_STABLE i386 after FreeBSD couldn't do it. It helps to have a UPS to protect against short power failures and allow graceful shutdown on longer power outages. Tom ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
fsck -y and SU+J
I see that if you run fsck on a filesystem with SU+J turned-on, fsck asks whether you want to use the journal. This causes a problem when running fsck -y. The traditional meaning of this command was: do a thorough, unconditional, non-interactive check; but now SU+J filesystems only get a journal sync. I can't even see the point in the question, surely someone that was content to use the journal would do a preen. This in 10-CURRENT. I'm not sure if it's like this in 9.1 or 9-STABLE, I only spent a week there trying to get intel kms graphics working on new hardware, so I'm new to SU+J. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9.1 and SU+J
On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote: On 03.11.2012 13:48, Doug Hardie wrote: I didn't notice that journaling is on by default and now dump is failing. The only way I can see to disable journaling requires that the file system be dismounted, or read-only. This is a remote machine and journaling is on root. Is there any other way that would not require me to make a long trip out to the site? This is a task for mfsBSD: http://mfsbsd.vx.sk Hmm, I think you have to make a trip or get some kind of remote console over ip. I tried it remote on a 9.1-RC2 system that has / /tmp /var and /usr as seperate partions For / i can do a mount -o ro / and tunefs -j disable /dev/da0p2 then mount -o rw / For the /tmp /var and /usr filesystems this does not work bcause hey cannot be remounted ro while they are busy. This e-mail message, including any attachment(s), is intended solely for the addressee or addressees. Any views or opinions presented herein are solely those of the author and do not necessarily represent those of OSE. If you are not the intended recipient of this communication please return this e-mail message and the attachment(s) to the sender and delete and destroy all copies. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9.1 and SU+J
On Sun, 04 Nov 2012 11:44:28 +0100 Bas Smeelen wrote: On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote: On 03.11.2012 13:48, Doug Hardie wrote: I didn't notice that journaling is on by default and now dump is failing. The only way I can see to disable journaling requires that the file system be dismounted, or read-only. This is a remote machine and journaling is on root. Is there any other way that would not require me to make a long trip out to the site? This is a task for mfsBSD: http://mfsbsd.vx.sk Hmm, I think you have to make a trip or get some kind of remote console over ip. I tried it remote on a 9.1-RC2 system that has / /tmp /var and /usr as seperate partions For / i can do a mount -o ro / and tunefs -j disable /dev/da0p2 then mount -o rw / For the /tmp /var and /usr filesystems this does not work bcause hey cannot be remounted ro while they are busy. A quick and dirty way to do it would be to edit /etc/rc.d/fsck and put your tunefs commands at the bottom of fsck_start(), then do a reboot. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9.1 and SU+J
On 11/04/2012 02:11 PM, RW wrote: On Sun, 04 Nov 2012 11:44:28 +0100 Bas Smeelen wrote: On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote: On 03.11.2012 13:48, Doug Hardie wrote: I didn't notice that journaling is on by default and now dump is failing. The only way I can see to disable journaling requires that the file system be dismounted, or read-only. This is a remote machine and journaling is on root. Is there any other way that would not require me to make a long trip out to the site? This is a task for mfsBSD: http://mfsbsd.vx.sk Hmm, I think you have to make a trip or get some kind of remote console over ip. I tried it remote on a 9.1-RC2 system that has / /tmp /var and /usr as seperate partions For / i can do a mount -o ro / and tunefs -j disable /dev/da0p2 then mount -o rw / For the /tmp /var and /usr filesystems this does not work bcause hey cannot be remounted ro while they are busy. A quick and dirty way to do it would be to edit /etc/rc.d/fsck and put your tunefs commands at the bottom of fsck_start(), then do a reboot. Very nice :) Thanks a lot! I tried this and can confirm it works. _But_ not all partitions are soft updates without journaling now. It didn't work for the / partition, I guess because / is mounted rw before /etc/rc.d/fsck is executed. For the / partition I guess I will really have to be at the console starting single user, because mount -o ro en then disable with tunefs -j disable did not work either. See at the end of this mail. I wonder if it even can be accomplished when booting single user, which I cannto test right now. Doug, if you have more partitions than just / you could go ahead with the above solution, it worked for me. You can then at least dump data from your other partitions. See below: root@osebart:/usr/home/Freebee # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, journaled soft-updates) /dev/da0p4 on /var (ufs, local, journaled soft-updates) /dev/da0p5 on /usr (ufs, local, journaled soft-updates) edit /etc/rc.d/fsck and added: /sbin/tunefs -j disable /dev/da0p2 /sbin/tunefs -j disable /dev/da0p3 /sbin/tunefs -j disable /dev/da0p4 /sbin/tunefs -j disable /dev/da0p5 just before } load_rc_config $name run_rc_command $1 at the end. shutdown -r now and I have root@osebart:/usr/home/Freebee # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) See below for mount -o ro root@osebart:/usr/home/Freebee # mount -o ro / root@osebart:/usr/home/Freebee # mount /dev/da0p2 on / (ufs, local, read-only) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) root@osebart:/usr/home/Freebee # tunefs -j disable /dev/da0p2 Clearing journal flags from inode 4 tunefs: soft updates journaling cleared but soft updates still set. tunefs: remove .sujournal to reclaim space shutdown -r now but still root@osebart:/usr/home/Freebee # mount /dev/da0p2 on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) This e-mail message, including any attachment(s), is intended solely for the addressee or addressees. Any views or opinions presented herein are solely those of the author and do not necessarily represent those of OSE. If you are not the intended recipient of this communication please return this e-mail message and the attachment(s) to the sender and delete and destroy all copies. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9.1 and SU+J
On 11/04/2012 03:00 PM, Bas Smeelen wrote: On 11/04/2012 02:11 PM, RW wrote: On Sun, 04 Nov 2012 11:44:28 +0100 Bas Smeelen wrote: On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote: On 03.11.2012 13:48, Doug Hardie wrote: I didn't notice that journaling is on by default and now dump is failing. The only way I can see to disable journaling requires that the file system be dismounted, or read-only. This is a remote machine and journaling is on root. Is there any other way that would not require me to make a long trip out to the site? I guess I was a little off here, it actually worked for / also See further below for the whole story This was all done remote with ssh $ mount /dev/da0p2 on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) $ su Password: root@osebart:/usr/home/Freebee # rm /.sujournal root@osebart:/usr/home/Freebee # rm /var/.sujournal root@osebart:/usr/home/Freebee # rm /tmp/.sujournal root@osebart:/usr/home/Freebee # rm /usr/.sujournal root@osebart:/usr/home/Freebee # uname -a FreeBSD osebart.ose.nl 9.1-RC2 FreeBSD 9.1-RC2 #0 r241106: Mon Oct 1 18:26:44 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 This is a task for mfsBSD: http://mfsbsd.vx.sk Hmm, I think you have to make a trip or get some kind of remote console over ip. I tried it remote on a 9.1-RC2 system that has / /tmp /var and /usr as seperate partions For / i can do a mount -o ro / and tunefs -j disable /dev/da0p2 then mount -o rw / For the /tmp /var and /usr filesystems this does not work bcause hey cannot be remounted ro while they are busy. A quick and dirty way to do it would be to edit /etc/rc.d/fsck and put your tunefs commands at the bottom of fsck_start(), then do a reboot. Very nice :) Thanks a lot! I tried this and can confirm it works. _But_ not all partitions are soft updates without journaling now. It didn't work for the / partition, I guess because / is mounted rw before /etc/rc.d/fsck is executed. For the / partition I guess I will really have to be at the console starting single user, because mount -o ro en then disable with tunefs -j disable did not work either. See at the end of this mail. I wonder if it even can be accomplished when booting single user, which I cannto test right now. Doug, if you have more partitions than just / you could go ahead with the above solution, it worked for me. You can then at least dump data from your other partitions. See below: root@osebart:/usr/home/Freebee # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, journaled soft-updates) /dev/da0p4 on /var (ufs, local, journaled soft-updates) /dev/da0p5 on /usr (ufs, local, journaled soft-updates) edit /etc/rc.d/fsck and added: /sbin/tunefs -j disable /dev/da0p2 /sbin/tunefs -j disable /dev/da0p3 /sbin/tunefs -j disable /dev/da0p4 /sbin/tunefs -j disable /dev/da0p5 just before } load_rc_config $name run_rc_command $1 at the end. shutdown -r now and I have root@osebart:/usr/home/Freebee # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) See below for mount -o ro root@osebart:/usr/home/Freebee # mount -o ro / root@osebart:/usr/home/Freebee # mount /dev/da0p2 on / (ufs, local, read-only) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) root@osebart:/usr/home/Freebee # tunefs -j disable /dev/da0p2 Clearing journal flags from inode 4 tunefs: soft updates journaling cleared but soft updates still set. tunefs: remove .sujournal to reclaim space shutdown -r now but still root@osebart:/usr/home/Freebee # mount /dev/da0p2 on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) This e-mail message, including any attachment(s), is intended solely for the addressee or addressees. Any views or opinions presented herein are solely those of the author and do not necessarily represent those of OSE. If you are not the intended recipient of this communication please return this e-mail message and the attachment(s) to the sender and delete and destroy all copies. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9.1 and SU+J
On 4 November 2012, at 07:04, Bas Smeelen wrote: On 11/04/2012 03:00 PM, Bas Smeelen wrote: On 11/04/2012 02:11 PM, RW wrote: On Sun, 04 Nov 2012 11:44:28 +0100 Bas Smeelen wrote: On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote: On 03.11.2012 13:48, Doug Hardie wrote: I didn't notice that journaling is on by default and now dump is failing. The only way I can see to disable journaling requires that the file system be dismounted, or read-only. This is a remote machine and journaling is on root. Is there any other way that would not require me to make a long trip out to the site? I guess I was a little off here, it actually worked for / also See further below for the whole story This was all done remote with ssh $ mount /dev/da0p2 on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) $ su Password: root@osebart:/usr/home/Freebee # rm /.sujournal root@osebart:/usr/home/Freebee # rm /var/.sujournal root@osebart:/usr/home/Freebee # rm /tmp/.sujournal root@osebart:/usr/home/Freebee # rm /usr/.sujournal root@osebart:/usr/home/Freebee # uname -a FreeBSD osebart.ose.nl 9.1-RC2 FreeBSD 9.1-RC2 #0 r241106: Mon Oct 1 18:26:44 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 I can't get that to work on i386. Here is /etc/rc.d/fsck: fi echo Ready for tunefs /sbin/tunefs -j disable /dev/da0p2 } load_rc_config $name run_rc_command $1 reboot computer and here is the output from messages: Nov 4 14:07:19 Router kernel: Ready for tunefs Nov 4 14:07:19 Router kernel: Clearing journal flags from inode 4 Nov 4 14:07:19 Router kernel: tunefs: soft updates journaling cleared but soft updates still set. Nov 4 14:07:19 Router kernel: tunefs: remove .sujournal to reclaim space Nov 4 14:07:19 Router kernel: Mounting local file systems:. and the output from mount: Router# mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) Journaled is still on after 2 reboots. Router# uname -a FreeBSD Router 9.1-RC2 FreeBSD 9.1-RC2 #0 r241133: Tue Oct 2 17:11:45 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 -- Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9.1 and SU+J
On 11/04/2012 11:18 PM, Doug Hardie wrote: On 4 November 2012, at 07:04, Bas Smeelen wrote: On 11/04/2012 03:00 PM, Bas Smeelen wrote: On 11/04/2012 02:11 PM, RW wrote: On Sun, 04 Nov 2012 11:44:28 +0100 Bas Smeelen wrote: On 11/03/2012 07:30 PM, Herbert J. Skuhra wrote: On 03.11.2012 13:48, Doug Hardie wrote: I didn't notice that journaling is on by default and now dump is failing. The only way I can see to disable journaling requires that the file system be dismounted, or read-only. This is a remote machine and journaling is on root. Is there any other way that would not require me to make a long trip out to the site? I guess I was a little off here, it actually worked for / also See further below for the whole story This was all done remote with ssh $ mount /dev/da0p2 on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/da0p3 on /tmp (ufs, local, soft-updates) /dev/da0p4 on /var (ufs, local, soft-updates) /dev/da0p5 on /usr (ufs, local, soft-updates) $ su Password: root@osebart:/usr/home/Freebee # rm /.sujournal root@osebart:/usr/home/Freebee # rm /var/.sujournal root@osebart:/usr/home/Freebee # rm /tmp/.sujournal root@osebart:/usr/home/Freebee # rm /usr/.sujournal root@osebart:/usr/home/Freebee # uname -a FreeBSD osebart.ose.nl 9.1-RC2 FreeBSD 9.1-RC2 #0 r241106: Mon Oct 1 18:26:44 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 I can't get that to work on i386. Here is /etc/rc.d/fsck: fi echo Ready for tunefs /sbin/tunefs -j disable /dev/da0p2 } load_rc_config $name run_rc_command $1 reboot computer and here is the output from messages: Nov 4 14:07:19 Router kernel: Ready for tunefs Nov 4 14:07:19 Router kernel: Clearing journal flags from inode 4 Nov 4 14:07:19 Router kernel: tunefs: soft updates journaling cleared but soft updates still set. Nov 4 14:07:19 Router kernel: tunefs: remove .sujournal to reclaim space Nov 4 14:07:19 Router kernel: Mounting local file systems:. and the output from mount: Router# mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) Journaled is still on after 2 reboots. Router# uname -a FreeBSD Router 9.1-RC2 FreeBSD 9.1-RC2 #0 r241133: Tue Oct 2 17:11:45 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 -- Doug Hi Doug This is bad. It did not work for me that way either on the / partition, but it worked on the other partitions. Because I have seperate /tmp /var and /usr partition I was able to mount the / partition readonly in multiuser mode with mount -o ro / and then tunefs -j disable and right after that reboot. It seems that somehow when the / partition gets mounted after disabling the journal, journaled soft updates is still set and thus still enabled, but with a reboot it gets cleared? I don't really understand this. This e-mail message, including any attachment(s), is intended solely for the addressee or addressees. Any views or opinions presented herein are solely those of the author and do not necessarily represent those of OSE. If you are not the intended recipient of this communication please return this e-mail message and the attachment(s) to the sender and delete and destroy all copies. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9.1 and SU+J
On 03.11.2012 13:48, Doug Hardie wrote: I didn't notice that journaling is on by default and now dump is failing. The only way I can see to disable journaling requires that the file system be dismounted, or read-only. This is a remote machine and journaling is on root. Is there any other way that would not require me to make a long trip out to the site? This is a task for mfsBSD: http://mfsbsd.vx.sk -- Herbert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
(Free 7.2) su -l didnt prompt password.Is it possbile?
Hello everyone. We'v noticed some strange situation. After reboot and login, system didn't ask for password while switchig with su -l. In details, there was root login from terminal and one from ssh. Terminal login was directly as root(via ip-console), and ssh was as user, then attemped switch to root with su -l, and there were NO password request,no prompt at all. At the same time login from terminal accepted root password, first I thought that means password wasn't empty, but system even with empty password should print Password:..and that time it was nothing absolultey. We even logged out and then su -l again. And It looked such way: %su -l St-serv# St-serv# exit %su -l St-serv# We'v been shocked and hurried a bit and changed root password without /etc/master.passwd backup for explorations. After chagning password we cant no reprocude such behaviour. It's also should be noticed that system was booting after unsafe power shutdown, and there was fs-check running in background(accroding to logs), corrected cleared some files(searching by inum resulted to nothing). sysctl -a gave such string: 118Starting background file system checks in 60 seconds. 118 and in /var/log/messages we could see: Jun 15 14:57:39 St-serv kernel: em0: link state changed to UP Jun 15 14:57:49 St-serv login: ROOT LOGIN (root) ON ttyv0 Jun 15 14:58:47 St-serv fsck: /dev/ad0s1e: 71 files, 11 used, 2538508 free (84 frags, 317303 blocks, 0.0% fragmentation) Jun 15 15:02:31 St-serv fsck: /dev/ad0s1f: 264646 files, 1378041 used, 60368113 free (43545 frags, 7540571 blocks, 0.1% fragmentation) Jun 15 15:03:31 St-serv su: zimmer to root on /dev/ttyp0 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT I=1931747 (897632 should be 897600) (CORRECTED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT I=1931748 (1865184 should be 1865120) (CORRECTED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT I=2284637 (4 should be 0) (CORRECTED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT I=2284713 (4 should be 0) (CORRECTED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: UNREF FILE I=23557 OWNER=root MODE=100644 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: SIZE=0 MTIME=Jun 9 18:51 2012 (CLEARED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: UNREF FILE I=1931319 OWNER=root MODE=100640 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: SIZE=728 MTIME=Jul 26 17:37 2011 (CLEARED) ... I'v googled and found only one thread with su didnt'asking for password, that one was abut jails, but this time we have a 100% garanty that we didnt put any virtual enviroments. So the thing that scares is, mb this is symptop of server rootkit? (We'v found nothing unusual in logs but it means nothing...) Or there is some other explanation why su could not ask password? Thanks in advance PS Duplicated question to freebsd-questions and freebsd-security because unsure which one it should be send. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
On 6/18/2012 9:31 AM, Budnev Vladimir wrote: And It looked such way: %su -l Before you enter this command, post the output of id ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
18.06.2012 18:02, Mike Tancsa написал: On 6/18/2012 9:31 AM, Budnev Vladimir wrote: And It looked such way: %su -l Before you enter this command, post the output of id Unfortunately, we can not flashback or reproduce that step now, cause we'v hurried and changed root password to avoid such strange free logins. And changing it back didnt change a thing. It was...and't went. We had only buffered console output :( But mb you can point in what case there is possibility to make su -l without any prompt. I suppose you mean that user has gid=0 or smthng like that but it hasn't. And as i mentioned changin root password to another and backwards doesn't allow to reproduce discribed behaviour. ---Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
On Jun 18, 2012 2:34 PM, Budnev Vladimir vladimir.bud...@gmail.com wrote: Hello everyone. We'v noticed some strange situation. After reboot and login, system didn't ask for password while switchig with su -l. In details, there was root login from terminal and one from ssh. Terminal login was directly as root(via ip-console), and ssh was as user, then attemped switch to root with su -l, and there were NO password request,no prompt at all. At the same time login from terminal accepted root password, first I thought that means password wasn't empty, but system even with empty password should print Password:..and that time it was nothing absolultey. Empty password behaviour is for no prompt, so what you are seeing is normal, and means that you did indeed have a empty password. Check your logs very carefully over the past few weeks to make sure no one has broken in. Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
On 6/18/2012 10:24 AM, Budnev Vladimir wrote: But mb you can point in what case there is possibility to make su -l without any prompt. If the uid is 0, you wont need to enter a passwd ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
18.06.2012 18:32, Chris Rees ???: On Jun 18, 2012 2:34 PM, Budnev Vladimir vladimir.bud...@gmail.com mailto:vladimir.bud...@gmail.com wrote: Hello everyone. We'v noticed some strange situation. After reboot and login, system didn't ask for password while switchig with su -l. In details, there was root login from terminal and one from ssh. Terminal login was directly as root(via ip-console), and ssh was as user, then attemped switch to root with su -l, and there were NO password request,no prompt at all. At the same time login from terminal accepted root password, first I thought that means password wasn't empty, but system even with empty password should print Password:..and that time it was nothing absolultey. Empty password behaviour is for no prompt, so what you are seeing is normal, and means that you did indeed have a empty password. Interesintg could it be that master.passwd file corrupted (after power shutdown) and fsck corrected in background.. which resulted in such behaviour. The strange thing with possibly empty password is that login from ip-console accepted correct password. So dont sure about empty...It seems like su was accepting any password at that time. Check your logs very carefully over the past few weeks to make sure no one has broken in. Yeah, seems we are forced to mount disks to another system and check for changes in critical system tools. Arghand then anyway redeploy system. Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
On Mon, Jun 18, 2012 at 05:31:54PM +0400, Budnev Vladimir wrote: Hello everyone. We'v noticed some strange situation. After reboot and login, system didn't ask for password while switchig with su -l. In details, there was root login from terminal and one from ssh. Terminal login was directly as root(via ip-console), and ssh was as user, then attemped switch to root with su -l, and there were NO password request,no prompt at all. At the same time login from terminal accepted root password, first I thought that means password wasn't empty, but system even with empty password should print Password:..and that time it was nothing absolultey. We even logged out and then su -l again. And It looked such way: %su -l St-serv# St-serv# exit %su -l St-serv# We'v been shocked and hurried a bit and changed root password without /etc/master.passwd backup for explorations. After chagning password we cant no reprocude such behaviour. It's also should be noticed that system was booting after unsafe power shutdown, and there was fs-check running in background(accroding to logs), corrected cleared some files(searching by inum resulted to nothing). sysctl -a gave such string: 118Starting background file system checks in 60 seconds. 118 and in /var/log/messages we could see: Jun 15 14:57:39 St-serv kernel: em0: link state changed to UP Jun 15 14:57:49 St-serv login: ROOT LOGIN (root) ON ttyv0 Jun 15 14:58:47 St-serv fsck: /dev/ad0s1e: 71 files, 11 used, 2538508 free (84 frags, 317303 blocks, 0.0% fragmentation) Jun 15 15:02:31 St-serv fsck: /dev/ad0s1f: 264646 files, 1378041 used, 60368113 free (43545 frags, 7540571 blocks, 0.1% fragmentation) Jun 15 15:03:31 St-serv su: zimmer to root on /dev/ttyp0 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT I=1931747 (897632 should be 897600) (CORRECTED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT I=1931748 (1865184 should be 1865120) (CORRECTED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT I=2284637 (4 should be 0) (CORRECTED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: INCORRECT BLOCK COUNT I=2284713 (4 should be 0) (CORRECTED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: UNREF FILE I=23557 OWNER=root MODE=100644 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: SIZE=0 MTIME=Jun 9 18:51 2012 (CLEARED) Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: UNREF FILE I=1931319 OWNER=root MODE=100640 Jun 15 15:03:43 St-serv fsck: /dev/ad0s1d: SIZE=728 MTIME=Jul 26 17:37 2011 (CLEARED) ... I'v googled and found only one thread with su didnt'asking for password, that one was abut jails, but this time we have a 100% garanty that we didnt put any virtual enviroments. So the thing that scares is, mb this is symptop of server rootkit? (We'v found nothing unusual in logs but it means nothing...) Or there is some other explanation why su could not ask password? The only thing I can think of ATM is .. did you recently perform and upgrade from source with this system ? mergemaster ? The reason why I ask is that when doing such things the master.passwd is compared to the default master.passwd which has no passowrd set. If a merge when wrong then there is a possibility that it was set back to defaults by accident. I also see that your system booted up and did a fsck(8). There is a chance that something wierd happened here as well. Thanks in advance PS Duplicated question to freebsd-questions and freebsd-security because unsure which one it should be send. ___ freebsd-secur...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org -- - (2^(N-1)) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
18.06.2012 18:37, Mike Tancsa написал: On 6/18/2012 10:24 AM, Budnev Vladimir wrote: But mb you can point in what case there is possibility to make su -l without any prompt. If the uid is 0, you wont need to enter a passwd Yeah i realized that you mean things came that way, but as I mentioned in prev mail, no gid or uid were 0, and we can not reproduce situation after password changing (we DID not changed any other system users) ---Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
I have only seen thuis after a source upgrade where mergemaster wants to remove the passwd. Has a source upgrade been done recently? Brian On Jun 18, 2012 7:26 AM, Budnev Vladimir vladimir.bud...@gmail.com wrote: 18.06.2012 18:02, Mike Tancsa написал: On 6/18/2012 9:31 AM, Budnev Vladimir wrote: And It looked such way: %su -l Before you enter this command, post the output of id Unfortunately, we can not flashback or reproduce that step now, cause we'v hurried and changed root password to avoid such strange free logins. And changing it back didnt change a thing. It was...and't went. We had only buffered console output :( But mb you can point in what case there is possibility to make su -l without any prompt. I suppose you mean that user has gid=0 or smthng like that but it hasn't. And as i mentioned changin root password to another and backwards doesn't allow to reproduce discribed behaviour. ---Mike __**_ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**questionshttp://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-** unsubscr...@freebsd.org freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
On 2012-06-18 16:41, Budnev Vladimir wrote: The strange thing with possibly empty password is that login from ip-console accepted correct password. So dont sure about empty...It seems like su was accepting any password at that time. That is the behavior with an empty password. The login would accept any password. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: (Free 7.2) su -l didnt prompt password.Is it possbile?
From owner-freebsd-questi...@freebsd.org Mon Jun 18 09:25:32 2012 Date: Mon, 18 Jun 2012 18:24:34 +0400 From: Budnev Vladimir vladimir.bud...@gmail.com To: Mike Tancsa m...@sentex.net Cc: freebsd-questions@freebsd.org Subject: Re: (Free 7.2) su -l didnt prompt password.Is it possbile? 18.06.2012 18:02, Mike Tancsa напиÑал: On 6/18/2012 9:31 AM, Budnev Vladimir wrote: And It looked such way: %su -l Before you enter this command, post the output of id Unfortunately, we can not flashback or reproduce that step now, cause we'v hurried and changed root password to avoid such strange free logins. And changing it back didnt change a thing. It was...and't went. We had only buffered console output :( But mb you can point in what case there is possibility to make su -l without any prompt.``o This _will_ happen if one is root, does 'su' to another user. and then another 'su' to root. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
UFS+SU+J and still background fs check?
Hi, When booting my computer today I noticed the message at the end: starting background filesystem check in 60 seconds. This seems strange to me since SU+J is enabled on all filesystems. How is this possible? NB running FreeBSD 9-STABLE Regards, Marco -- In most instances, all an argument proves is that two people are present. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS+SU+J and still background fs check?
On Mon, 30 Jan 2012 13:17:16 +0100 (CET) Marco Beishuizen wrote: Hi, When booting my computer today I noticed the message at the end: starting background filesystem check in 60 seconds. This seems strange to me since SU+J is enabled on all filesystems. How is this possible? NB running FreeBSD 9-STABLE It just means that the fsck process that would perform background fsck for any filesystem that supports it and isn't clean will run in 60 second. You can turn it off with background_fsck=NO in rc.conf, which will disable background fsck support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
portupgrade -P does not 'su'?
Hello. I'd like to install a port with 'portinstall -P' from a non-root user and it requires an obvious dependency I already have built to be reused. But portinstall doesn't seem to brace it into the 'su root -c': $ portinstall -vpP devel/p5-Test-Class [..] --- Installing 'p5-Module-Build-0.3800_1' from a package --- Installation of p5-Module-Build-0.3800_1 started at: Mon, 07 Nov 2011 15:57:56 +0400 --- Installing the new version via the package lib/perl5/5.14.1/man/man3/inc::latest.3.gz: Can't create 'lib/perl5/5.14.1/man/man3/inc::latest.3.gz': Permission denied [..] ** Command failed [exit code 2]: /usr/bin/script -qa /tmp/portinstall2007-84470-1midf4x-0 /usr/bin/env UPGRADE_TOOL=portupgrade UPGRADE_PORT=p5-Module-Build-0.3800_1 UPGRADE_PORT_VER=0.3800_1 /usr/sbin/pkg_add -f /usr/ports/packages/All/p5-Module-Build-0.3800_1.tbz It does use to be all ok with 'pkg_delete ... make install' sequence though. Any clues? ps. Same goes here about copying the obsoleted shared libraries to /usr/local/lib/compat/pkg -- Peter Vereshagin pe...@vereshagin.org (http://vereshagin.org) pgp: A0E26627 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Kerberos and su to root
I have multiple systems and jails at my home. I would very much like to implement a single sign on strategy with kerberos. I think it's safer than having private keys on every single box. I can easily do this for shh user logins to multiple boxes. But I like to sign in as a user and then su to root when I get there. (Forget about sudo, I am administering these boxes and don't want to type sudo for every single command, it's not a user machine). From what I understand of Kerberos I would need change identity and type a password every time I ksu which is what I'm trying to avoid. Am I right that it is imposable to maintain multiple simultaneous credentials and get the right one to automatically be used? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
su always works if pam config missing
The su(1) command always provide root access if there are no pam config files. Is this actually the desired behavior? Regards, Jason C. Wells ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU
are you logged as su, and can't execute commands ? or does su fail ?
if you're correctly identified, what does your env and/or set contains
Samuel Martín Moro
CamTrace
{EPITECH.} tek4
Nobody wants to say how this works.
Maybe nobody knows ...
Xorg.conf(5)
On Tue, Jan 26, 2010 at 1:04 AM, Jon Radel j...@radel.com wrote:
Shone Russell wrote:
I am not able to execute any commands when I utilize the su function, I
am entering our correct password. It was working on Friday, but now it's
not.
Please let us know exactly what you're entering (without the password, of
course) and what the results are. Do you get an error message? Does it
hang? What?
--
--Jon Radel
j...@radel.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
SU
I am not able to execute any commands when I utilize the su function, I am entering our correct password. It was working on Friday, but now it's not. Also can you tell me how to install the module for Bacula, or Amanda I keep getting an error message that module.info is missing. My phone number is 973-244-0555 ext 39 Thanks FreeBSD WEB01 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: SU
Shone Russell wrote: I am not able to execute any commands when I utilize the su function, I am entering our correct password. It was working on Friday, but now it's not. Please let us know exactly what you're entering (without the password, of course) and what the results are. Do you get an error message? Does it hang? What? -- --Jon Radel j...@radel.com smime.p7s Description: S/MIME Cryptographic Signature
RE: SU Question
Sorry, I figured the problem, I edited the group file and added my name to the group wheel and still not getting su to work. VJ Viraj Dixit City of Palo Alto Information Technology 650-329-2118 From: Dixit, Viraj Sent: Thursday, April 30, 2009 3:34 PM To: 'freebsd-questions@freebsd.org' Subject: RE: SU Question Hi, I just installed Free BSD OS 7.1 and installation went without any errors, all looks good till I try to login with SU account via telnet and I get this error below. Please help!! VJ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: SU Question
Hi, I just installed Free BSD OS 7.1 and installation went without any errors, all looks good till I try to login with SU account via telnet and I get this error below. Please help!! VJ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: SU Question
Sorry, I have the answer, my apologize to all. VJ Viraj Dixit City of Palo Alto Information Technology 650-329-2118 From: Dixit, Viraj Sent: Thursday, April 30, 2009 3:46 PM To: 'freebsd-questions@freebsd.org' Subject: RE: SU Question Sorry, I figured the problem, I edited the group file and added my name to the group wheel and still not getting su to work. VJ Viraj Dixit City of Palo Alto Information Technology 650-329-2118 From: Dixit, Viraj Sent: Thursday, April 30, 2009 3:34 PM To: 'freebsd-questions@freebsd.org' Subject: RE: SU Question Hi, I just installed Free BSD OS 7.1 and installation went without any errors, all looks good till I try to login with SU account via telnet and I get this error below. Please help!! VJ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
su qeustion
I just installed FreeBSD with Gnome. And I changed the shell when I was logged ito the terminal as su root. Now when I try to log in to su it asks for a password and I get su: /usr/bin/csh: No such file or directory how can I change it back. Thanks Jonathan Moore ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: su qeustion
On Dec 17, 2008, at 12:12 PM, Jonathan Moore wrote: I just installed FreeBSD with Gnome. And I changed the shell when I was logged ito the terminal as su root. Now when I try to log in to su it asks for a password and I get su: /usr/bin/csh: No such file or directory how can I change it back. Reboot into single-user mode, which will give you a /bin/sh root shell, run vipw, and fix the root shell to be /bin/csh. Or, if you have sudo available, you can use that directly to get a root shell and fix it without needing to hit single-user mode Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: su qeustion
On Dec 17, 2008, at 3:12 PM, Jonathan Moore wrote: I just installed FreeBSD with Gnome. And I changed the shell when I was logged ito the terminal as su root. Now when I try to log in to su it asks for a password and I get su: /usr/bin/csh: No such file or directory how can I change it back. su root -c /bin/sh and then change the shell to /bin/csh -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Behaviour of su(1)
Le Vendredi 31 à 20:27, Fred Condo a écrit : Use this syntax (both equivalent): su - root su -l root You do have to specify the user with -l. Perhaps the man page could clarify that. I read the first line that says The su utility requests appropriate user credentials via PAM and switches to that user ID (the default user is the superuser) as 'su -' and 'su - root' are equivalent. su -l root as the expected behaviour (resetting $LOGNAME to $USER), thanks a lot. On Oct 31, 2008, at 11:33 AM, Frédéric Perrin wrote: As a side question, is it considered bad practice to set root's shell and locales to something else than the default ? -- Fred ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Behaviour of su(1)
On Friday 31 October 2008 19:33:44 Frédéric Perrin wrote: As a side question, is it considered bad practice to set root's shell and locales to something else then the default ? By some (most?) yes. If you decide to change the default shell, to one that's not in the base system (i.e., a ksh/zsh/bash port), then it's highly recommended to make a static version that installs into /bin. This will save you a number of headaches, when a library dependency is (unsuccessfully or partially) upgraded or /usr is not accessable. However, when reporting bugs and you only slightly suspect it to be shell related, you should be able to reproduce it on csh for the purpose of reporting and adjust the bugreport if you can not. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Behaviour of su(1)
Hello, When I « su - » to root (after being logged in as my normal user), the LOGNAME env variable is still set to my previous user, as in : , | [EMAIL PROTECTED]:~% /usr/bin/su -l | Password: | [EMAIL PROTECTED]:~# echo $USER - $LOGNAME | root - fred ` As far as I can tell, this contradicts the fine manual that says : , | -l Simulate a full login. The environment is discarded except for | HOME, SHELL, PATH, TERM, and USER. ` So I would have expected LOGNAME to be either empty or set by some shell startup script to be root. So, why is LOGNAME still equal to my previous user ? (and where is it set ? « grep -r LOGNAME /etc » doesn't turn up anything...) This is an issue because emacs, for instance, uses $LOGNAME to load the init-file. I could always add « export LOGNAME=root » to my shell startup file, but this doesn't quite feel right... GNU su (as it is ocnfigured in Debian at least) resets LOGNAME to root in the same situation. (and by the way, GNU su seems broken : if I « gsu -l root », I always get a 'Password incorrect' answer). As a side question, is it considered bad practice to set root's shell and locales to something else then the default ? -- Fred ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Behaviour of su(1)
Hi-- On Oct 31, 2008, at 11:33 AM, Frédéric Perrin wrote: When I « su - » to root (after being logged in as my normal user), the LOGNAME env variable is still set to my previous user, as in : , | [EMAIL PROTECTED]:~% /usr/bin/su -l | Password: | [EMAIL PROTECTED]:~# echo $USER - $LOGNAME | root - fred ` As far as I can tell, this contradicts the fine manual that says : , | -l Simulate a full login. The environment is discarded except for | HOME, SHELL, PATH, TERM, and USER. ` So I would have expected LOGNAME to be either empty or set by some shell startup script to be root. So, why is LOGNAME still equal to my previous user ? (and where is it set ? « grep -r LOGNAME /etc » doesn't turn up anything...) When you su -l it invokes /usr/bin/login, which per man login sets up up $LOGNAME: The login utility enters information into the environment (see environ(7)) specifying the user's home directory (HOME), command inter- preter (SHELL), search path (PATH), terminal type (TERM) and user name (both LOGNAME and USER). I believe it looks up the actual username from the wtmp record associated with your open tty, so $USER corresponds to the effective userid, but $LOGNAME corresponds to the actual username used to login, aka your real userid...? Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Behaviour of su(1)
Use this syntax (both equivalent): su - root su -l root You do have to specify the user with -l. Perhaps the man page could clarify that. On Oct 31, 2008, at 11:33 AM, Frédéric Perrin wrote: Hello, When I « su - » to root (after being logged in as my normal user), the LOGNAME env variable is still set to my previous user, as in : , | [EMAIL PROTECTED]:~% /usr/bin/su -l | Password: | [EMAIL PROTECTED]:~# echo $USER - $LOGNAME | root - fred ` As far as I can tell, this contradicts the fine manual that says : , | -l Simulate a full login. The environment is discarded except for | HOME, SHELL, PATH, TERM, and USER. ` So I would have expected LOGNAME to be either empty or set by some shell startup script to be root. So, why is LOGNAME still equal to my previous user ? (and where is it set ? « grep -r LOGNAME /etc » doesn't turn up anything...) This is an issue because emacs, for instance, uses $LOGNAME to load the init-file. I could always add « export LOGNAME=root » to my shell startup file, but this doesn't quite feel right... GNU su (as it is ocnfigured in Debian at least) resets LOGNAME to root in the same situation. (and by the way, GNU su seems broken : if I « gsu -l root », I always get a 'Password incorrect' answer). As a side question, is it considered bad practice to set root's shell and locales to something else then the default ? -- Fred ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
On Friday 24 October 2008 23:59, Jos Chrispijn wrote: [Jeremy Chadwick said] You're trying to solve a social (possibly personal?) problem with technology. Simply put, this is a bad idea. Yep, I think that is .true. I would highly recommend you either talk to the idiot and explain to him why what he's doing is improper or foolish, or simply pull his root access entirely. If this is a work-related incident, talk to your boss about it if at all possible (but see below). If you call the shots, simply yank their access. The idiot is the boss himself and acts like an unguided missile. Just investigating before I give him a wake-up call. And that is exactly what I will do... Food for thought. Cheers! Love it, thanks for sharing (everyone)! I'm coming to this discussion a bit late, and in general it's true that you can't limit root's ability to read files, execute programs, fiddle with settings etc. What you can do, which has limited usefulness but might fit your specific case, is temporarily prevent root from using su to log in as another user without knowing their password. If you comment out (or remove entirely, which may slow down the other user even more, if they're unfamiliar with pam) the line authsufficient pam_rootok.so no_warn in /etc/pam.d/su, root has to meet the same requirements as any other user before using su. Of course there's nothing to stop someone with root access from editing this file, but now the problem user has to actively subvert a measure that's been taken by another sysadmin - which may provide a better starting-point for a conversation about what they're up to. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
root | su
Is there a way of stopping root from su'ing to another user? Jos Chrispijn ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
On Fri, Oct 24, 2008 at 2:06 PM, Jos Chrispijn [EMAIL PROTECTED] wrote: Is there a way of stopping root from su'ing to another user? Short of disabling the user account you are `su'ing to (or disabling root), no. Root can do anything. -- Glen Barber ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
Jos Chrispijn wrote: Is there a way of stopping root from su'ing to another user? Jos Chrispijn ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Root is supposed to be the almighty god on your machine (i.e. you...). No point trying to limit the abilities of root (especially if physical access is also provided). And seriously, root is a role not a person. If you find yourself trying to limit root's capabilities, you've probably surrendered the root password to the wrong person. If you need to give someone limited root access to a machine, just use security/sudo instead (with a carefully crafted sudoers file). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
Jos Chrispijn wrote: Is there a way of stopping root from su'ing to another user? what kind of question is this? -- en0f ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
--- On Fri, 10/24/08, Manolis Kiagias [EMAIL PROTECTED] wrote: From: Manolis Kiagias [EMAIL PROTECTED] Subject: Re: root | su To: Jos Chrispijn [EMAIL PROTECTED] Cc: FreeBSD Questions freebsd-questions@freebsd.org Date: Friday, October 24, 2008, 2:25 PM Jos Chrispijn wrote: Is there a way of stopping root from su'ing to another user? Jos Chrispijn Root is supposed to be the almighty god on your machine (i.e. you...). No point trying to limit the abilities of root (especially if physical access is also provided). And seriously, root is a role not a person. If you find yourself trying to limit root's capabilities, you've probably surrendered the root password to the wrong person. If you need to give someone limited root access to a machine, just use security/sudo instead (with a carefully crafted sudoers file). That's one option. Another is to implement jails, or virtualization via something like qemu. Since the person asking didn't give any details of what he wants to do, it's hard to say, but your point is correct regardless. - mdh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
en0f wrote: Jos Chrispijn wrote: Is there a way of stopping root from su'ing to another user? what kind of question is this? Obviously one that brings out of the woodwork the type of people with closed and non-inquisitive minds... probably the type of people who think that they have all of life's questions answered :) Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
Since the person asking didn't give any details of what he wants to do, it's hard to say, but your point is correct regardless. The idea behind my question is this: I am responsible for a server on which an(other) idiot keeps loggin in as user root, allthough he has his own user account and is part of the wheel group. To prevent this nub to change any other user account in God mode, I am searching for a solutions on this. jc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
Jos Chrispijn wrote: Since the person asking didn't give any details of what he wants to do, it's hard to say, but your point is correct regardless. The idea behind my question is this: I am responsible for a server on which an(other) idiot keeps loggin in as user root, allthough he has his own user account and is part of the wheel group. To prevent this nub to change any other user account in God mode, I am searching for a solutions on this. Instead of using the root account, could you make him use sudo, without the ability to su? Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
--- On Fri, 10/24/08, Jos Chrispijn [EMAIL PROTECTED] wrote: From: Jos Chrispijn [EMAIL PROTECTED] Subject: Re: root | su To: Cc: freebsd-questions@freebsd.org Date: Friday, October 24, 2008, 4:45 PM Since the person asking didn't give any details of what he wants to do, it's hard to say, but your point is correct regardless. The idea behind my question is this: I am responsible for a server on which an(other) idiot keeps loggin in as user root, allthough he has his own user account and is part of the wheel group. To prevent this nub to change any other user account in God mode, I am searching for a solutions on this. Disable direct access via whatever remote access method you use as root. Thus the other individual will have to login as themself, and su to root. If you do not wish them to su to root, change the root password. - mdh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: root | su
On Fri, Oct 24, 2008 at 10:45:04PM +0200, Jos Chrispijn wrote: Since the person asking didn't give any details of what he wants to do, it's hard to say, but your point is correct regardless. The idea behind my question is this: I am responsible for a server on which an(other) idiot keeps loggin in as user root, allthough he has his own user account and is part of the wheel group. To prevent this nub to change any other user account in God mode, I am searching for a solutions on this. You're trying to solve a social (possibly personal?) problem with technology. Simply put, this is a bad idea. I would highly recommend you either talk to the idiot and explain to him why what he's doing is improper or foolish, or simply pull his root access entirely. If this is a work-related incident, talk to your boss about it if at all possible (but see below). If you call the shots, simply yank their access. Here's you a story, maybe to lighten up my above criticism. I hope you enjoy it. Back in the early-to-mid-90s I worked at a small ISP in Palo Alto as a combination junior SA (sans root) and phone support monkey. There were two people who had root access on the FreeBSD boxes: one fellow was a clueful, friendly, and very technical UNIX system administrator (also partial owner), and another fellow (also partial owner) who was a complete tool -- imagine Dilbert's boss with basic UNIX CLI and how to plug in Ethernet knowledge. One day, we got some phone calls from customers stating they were having authentication dial-up problems or something (I can't remember). I didn't have root access to determine what the problem was, so I called up the UNIX SA and told him what was going on. He sighed, then agreed to take a look. About 15 minutes later he called back stating he'd fixed it. The next day, we started getting calls from customers again -- same issue. I called the SA (didn't you fix this yesterday?!?!), he sighed again, and 15 minutes later had it fixed. I asked what the deal was, and all he said was I'll explain it next time I'm in the office. A few weeks later I saw him and reminded him of the incident. The other individual who had root -- who also just happened to be my boss -- had gotten on the box in the middle of the night and decided to basically screw with things, telling no one. After the UNIX SA had fixed things the first time, that night my boss went back and screwed with things a second time, leaving things in a completely broken state again -- and like before, told no one. How is this even possible? I asked. The SA explained that he had worked with my boss at previous jobs, and he was known for doing this sort of thing, hence the sighing. I believe his words were Whenever something crazy would happen to the systems at old job, we'd almost always find traces of boss having logged in and modified seemingly random config files, broke things, and left them that way. He'd often do this at absurd hours of the night, almost as if he didn't want someone catching him in the process. I asked how he dealt with the situation, and he said At the previous job? His root access was eventually removed, as it was the only way. At this job? Well, let's just say the Email conversation is quite heated and will soon be involving the guys who financially back us. Food for thought. Cheers! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
[SOLVED] Re: root | su
You're trying to solve a social (possibly personal?) problem with technology. Simply put, this is a bad idea. Yep, I think that is .true. I would highly recommend you either talk to the idiot and explain to him why what he's doing is improper or foolish, or simply pull his root access entirely. If this is a work-related incident, talk to your boss about it if at all possible (but see below). If you call the shots, simply yank their access. The idiot is the boss himself and acts like an unguided missile. Just investigating before I give him a wake-up call. And that is exactly what I will do... Food for thought. Cheers! Love it, thanks for sharing (everyone)! jc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can an Account be Locked out for ssh but allow su?
Personally I prefer AllowUsers, as that denies all users except those specifically allowed. Deny/AllowGroups are useful too. 2008/10/8 Martin McCormick [EMAIL PROTECTED] Henrik Hudson writes: Check the sshd_config man page for AllowUsers and DenyUsers directives. Many thanks. DenyUsers did the trick. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Can an Account be Locked out for ssh but allow su?
Is there a way to configure an account such that one can su - this-account from another login on the system, but not ssh directly in to it from the outside, similar to the way root works if you set the terminal type in /etc/ttys to insecure? The idea is to make a common place for group projects but know who logged in and su'd in to this common space. We don't care if they logged in as themselves via ssh but we do care if they log in as this common user because we then don't know who accidentally deleted all the files or whatever accident one can imagine. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Telecommunications Services Group ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can an Account be Locked out for ssh but allow su?
On Wednesday 08 October 2008, Martin McCormick [EMAIL PROTECTED] sent a missive stating: Is there a way to configure an account such that one can su - this-account from another login on the system, but not ssh directly in to it from the outside, similar to the way root works if you set the terminal type in /etc/ttys to insecure? Check the sshd_config man page for AllowUsers and DenyUsers directives. THis should do what you want. Henrik -- Henrik Hudson [EMAIL PROTECTED] -- God, root, what is difference? Pitr; UF (http://www.userfriendly.org/) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can an Account be Locked out for ssh but allow su?
Henrik Hudson writes: Check the sshd_config man page for AllowUsers and DenyUsers directives. Many thanks. DenyUsers did the trick. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
su: _secure_path: cannot stat /dev/null/.login_conf: Not a directory, Any help?
Hi On the screen it says su: _secure_path: cannot stat /dev/null/.login_conf: Not a directory Any help to correct this problem? -- Thanks! BR / vj ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtprio + su - doesn't work
tu run (at startup) asterisk PBX as user centrala with realtime priority. asterisk is started, but without realtime priority. Yes, you'd be running the su process with realtime priority. :-) and su forks shell and asterisk - isn't it? how to do this right? i run asterisk as user (not root), but this server is used to other things, so asterisk must have absolute priority over other things. now i have to do this manually by searching for asterisk's PID and doing rtprio 31 -PID Well, you have to run rtprio as root, or else make it setuid-root (which probably isn't a great idea). Presumably this thing has a startup script which runs it, and it probably creates a PID file under /var/run which you could use to adjust the priority during system startup via: rtprio 31 -`cat /var/run/asterix.pid` did this /usr/bin/su centrala -c \ /usr/local/sbin/asterisk -C /centrala/etc/asterisk.conf /bin/sleep 5 /usr/sbin/rtprio 31 -`cat /centrala/run/asterisk.pid` works fine, but looks like workaround for me not proper solution? am i wrong? thank you for explanation why it doesn't work directly Wojtek ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtprio + su - doesn't work
Wojciech Puchar wrote: /usr/sbin/rtprio 31 /usr/bin/su centrala -c \ /usr/local/bin/asterisk -C /centrala/etc/asterisk.conf asterisk is started, but without realtime priority. I'm not sure what's wrong, but it works fine for me: # rtprio 31 su -m nobody -c 'id; /usr/sbin/rtprio' uid=65534(nobody) gid=65534(nobody) groups=65534(nobody) rtprio: realtime priority 31 # This is on 7-stable (a few months old, though). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I have stopped reading Stephen King novels. Now I just read C code instead. -- Richard A. O'Keefe ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtprio + su - doesn't work
I'm not sure what's wrong, but it works fine for me: # rtprio 31 su -m nobody -c 'id; /usr/sbin/rtprio' uid=65534(nobody) gid=65534(nobody) groups=65534(nobody) rtprio: realtime priority 31 # This is on 7-stable (a few months old, though). i have 7 stable too. no idea :) maybe asterisk have something in it's code that drops that privilege. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtprio + su - doesn't work
On Aug 22, 2008, at 6:28 AM, Wojciech Puchar wrote: tu run (at startup) asterisk PBX as user centrala with realtime priority. asterisk is started, but without realtime priority. Yes, you'd be running the su process with realtime priority. :-) and su forks shell and asterisk - isn't it? That's right. RT priority isn't inherited by children processes, or so it seems. [ ... ] Well, you have to run rtprio as root, or else make it setuid-root (which probably isn't a great idea). Presumably this thing has a startup script which runs it, and it probably creates a PID file under /var/run which you could use to adjust the priority during system startup via: rtprio 31 -`cat /var/run/asterix.pid` did this /usr/bin/su centrala -c \ /usr/local/sbin/asterisk -C /centrala/etc/asterisk.conf /bin/sleep 5 /usr/sbin/rtprio 31 -`cat /centrala/run/asterisk.pid` works fine, but looks like workaround for me not proper solution? am i wrong? thank you for explanation why it doesn't work directly Very few people do anything with RT priorities, in part because Unix was designed to maximize workload throughput originally in a batch- processing context. People who need hard realtime tend to use more specialized systems and hardware designed for realtime tasks (ie, bounded interrupt service times and the like)... -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
rtprio + su - doesn't work
i run such command /usr/sbin/rtprio 31 /usr/bin/su centrala -c \ /usr/local/bin/asterisk -C /centrala/etc/asterisk.conf tu run (at startup) asterisk PBX as user centrala with realtime priority. asterisk is started, but without realtime priority. how to do this right? i run asterisk as user (not root), but this server is used to other things, so asterisk must have absolute priority over other things. now i have to do this manually by searching for asterisk's PID and doing rtprio 31 -PID thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtprio + su - doesn't work
On Aug 21, 2008, at 2:04 PM, Wojciech Puchar wrote: i run such command /usr/sbin/rtprio 31 /usr/bin/su centrala -c \ /usr/local/bin/asterisk -C /centrala/etc/asterisk.conf tu run (at startup) asterisk PBX as user centrala with realtime priority. asterisk is started, but without realtime priority. Yes, you'd be running the su process with realtime priority. :-) how to do this right? i run asterisk as user (not root), but this server is used to other things, so asterisk must have absolute priority over other things. now i have to do this manually by searching for asterisk's PID and doing rtprio 31 -PID Well, you have to run rtprio as root, or else make it setuid-root (which probably isn't a great idea). Presumably this thing has a startup script which runs it, and it probably creates a PID file under /var/run which you could use to adjust the priority during system startup via: rtprio 31 -`cat /var/run/asterix.pid` -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with sendmail and su
Hello. I use FreeBSD 7 with sendmail. I have a problem for sending email. More precisely, with the sender of the mail. When I'm logged to my machine in root, the mail is sent with [EMAIL PROTECTED] with sender. OK, no problems. When I'm logged to my machine in nicolas, the mail is sent with [EMAIL PROTECTED] with sender. OK, no problems. However, when I'm logged in nicolas to my machine, and if I do a su root or su - root, and I send a mail, the sender will be [EMAIL PROTECTED] and not [EMAIL PROTECTED]. It's a problem, because I done a su to be logged as root. I don't have this problem with a FreeBSD/Postfix. Thanks for your advices and helps. I don't understand this problem. Regards, -- - Nicolas. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with sendmail and su
At 05:44 AM 7/9/2008, Nicolas Letellier wrote: Hello. I use FreeBSD 7 with sendmail. I have a problem for sending email. More precisely, with the sender of the mail. When I'm logged to my machine in root, the mail is sent with [EMAIL PROTECTED] with sender. OK, no problems. When I'm logged to my machine in nicolas, the mail is sent with [EMAIL PROTECTED] with sender. OK, no problems. However, when I'm logged in nicolas to my machine, and if I do a su root or su - root, and I send a mail, the sender will be [EMAIL PROTECTED] and not [EMAIL PROTECTED]. It's a problem, because I done a su to be logged as root. I don't have this problem with a FreeBSD/Postfix. Thanks for your advices and helps. I don't understand this problem. Regards, -- - Nicolas. That is exactly working as designed. The reason sendmail sends the mail as your actual login user is so you cannot spoof so easily. If you have certain emails like system reports you are sending and want them sent as root, add them to roots crontab file. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
cant su to root
When i try to su to root from konsole within kde it tells me.. $ su su: Sorry i got a feeling when i added my user client to operators group this may have done this an sadly now i cant run or do anything that requires root access. Any thoughts? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cant su to root
On Tuesday 01 July 2008, Warren Liddell said: When i try to su to root from konsole within kde it tells me.. $ su su: Sorry i got a feeling when i added my user client to operators group this may have done this an sadly now i cant run or do anything that requires root access. Any thoughts? Can you log into root directly? If so make sure your user is part of the wheel group then you should be able to su to root. If not you'll have to boot into single user and change the root password you have access then do the above. -- --- Beech Rintoul - FreeBSD Developer - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.FreeBSD.org/releases/7.0R/announce.html --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cant su to root
Warren Liddell wrote: When i try to su to root from konsole within kde it tells me.. $ su su: Sorry i got a feeling when i added my user client to operators group this may have done this an sadly now i cant run or do anything that requires root access. Any thoughts? wheel group ;-) Peter -- http://www.boosten.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cant su to root
Le Tue, 1 Jul 2008 20:43:21 +1000, Warren Liddell [EMAIL PROTECTED] a écrit : Hi, When i try to su to root from konsole within kde it tells me.. $ su su: Sorry i got a feeling when i added my user client to operators group this may have done this an sadly now i cant run or do anything that requires root access. Any thoughts? The user must be in the group wheel. Regards. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: cant su to root
It should have been added to the wheel group if you wanted to su from it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Warren Liddell Sent: Tuesday, July 01, 2008 12:43 PM To: freebsd-questions@freebsd.org Subject: cant su to root When i try to su to root from konsole within kde it tells me.. $ su su: Sorry i got a feeling when i added my user client to operators group this may have done this an sadly now i cant run or do anything that requires root access. Any thoughts? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] __ NOD32 3223 (20080627) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
