Re: csh/tcsh: odd %~ prompt variable behaviour
Sorry, I meant to include that with my previous mail.
echo $version
tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-unknown-linux) options
wide,nls,dl,al,kan,rh,nd,color,filec
Let me know if you need any more info.
On Tue, Feb 5, 2013 at 10:25 PM, Jeremy Chadwick wrote:
> Michael,
>
> Thank you very much! What tcsh version is that? "echo $version" should
> say. :-)
>
> --
> | Jeremy Chadwick j...@koitsu.org |
> | UNIX Systems Administratorhttp://jdc.koitsu.org/ |
> | Mountain View, CA, US|
> | Making life hard for others since 1977. PGP 4BD6C0CB |
>
> On Tue, Feb 05, 2013 at 10:05:44PM -0800, Galati, Michael wrote:
> > Looks like it could be FreeBSD specific... I very rarely use {,t}csh
> > myself.
> >
> > user@host:~$ uname -a
> > Linux host 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:15:40 UTC 2013
> > x86_64 x86_64 x86_64 GNU/Linux
> > user@host:~$ sudo -i
> > [sudo] password for user:
> > root@host:~# tcsh
> > host:~# set prompt = "%N@%m:%~ %# "
> > root@host:~ # asdfasdf
> > asdfasdf: Command not found.
> > root@host:~ # cd ~user
> > root@host:~user # asdfasdf
> > asdfasdf: Command not found.
> > root@host:~user # exit
> > root@host:~# logout
> >
> >
> >
> > On Tue, Feb 5, 2013 at 5:10 PM, Jeremy Chadwick wrote:
> >
> > > (Please keep me CC'd as I'm not subscribed to the list)
> > >
> > >
> > > System is base/stable/9, r245697. tcsh version is 6.18.01:
> > >
> > > $ sudo -i
> > > root@icarus:~ # sfdjsdj
> > > sfdjsdj: Command not found.
> > > root@icarus:~ # cd ~root
> > > root@icarus:~ # dsjfdsfdsf
> > > dsjfdsfdsf: Command not found.
> > > root@icarus:~ # cd ~jdc
> > > root@icarus:~jdc # sdjfdjkfjdsk
> > > sdjfdjkfjdsk: Command not found.
> > > root@icarus:/home/jdc # < notice sudden prompt change
> > > root@icarus:/home/jdc # cd ~root
> > > root@icarus:~ # dsfjjdskdfs
> > > dsfjjdskdfs: Command not found.
> > > root@icarus:~ # logout
> > >
> > > This only happens when an invalid command is issued (e.g. had I used
> > > "ls" instead of "blah" the prompt would not have changed).
> > >
> > > $prompt is the standard /root/.cshrc (r244005) value:
> > >
> > > set prompt = "%N@%m:%~ %# "
> > >
> > > I cannot reproduce this problem on Debian 6.0.1 with tcsh 6.17.02:
> > >
> > > $ ssh jdc@192.168.1.161
> > > Linux debian 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686
> > >
> > > Last login: Tue Feb 3 19:22:19 2013 from icarus.home.lan
> > > jdc@debian:~$ sudo -i
> > > root@debian:~# /bin/tcsh
> > > debian:~# set prompt = "%N@%m:%~ %# "
> > > root@debian:~ # sdfsdf
> > > sdfsdf: Command not found.
> > > root@debian:~ # cd ~jdc
> > > root@debian:~jdc # sdfssgsgjsj
> > > sdfssgsgjsj: Command not found.
> > > root@debian:~jdc # exit
> > > root@debian:~# logout
> > >
> > > The number of changes between 6.17.02 and 6.18.01 seem quite large
> > > (looking at src/contrib/tcsh/Fixes).
> > >
> > > Does anyone have a non-FreeBSD system with tcsh 6.18.01 available
> > > to determine if this is a FreeBSD-centric issue or an actual issue with
> > > tcsh that needs to be reported upstream?
> > >
> > > Thanks.
> > >
> > > --
> > > | Jeremy Chadwick j...@koitsu.org |
> > > | UNIX Systems Administratorhttp://jdc.koitsu.org/ |
> > > | Mountain View, CA, US|
> > > | Making life hard for others since 1977. PGP 4BD6C0CB |
> > >
> > > ___
> > > freebsd-stable@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > To unsubscribe, send any mail to "
> freebsd-stable-unsubscr...@freebsd.org"
> > >
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic at shutdown
Without so much as a stack trace there is nothing to chew on. A useable vmcore would be better. Did you perhaps use kgdb with a mismatching kernel? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic at shutdown
On 07/02/2013 09:55, Andriy Gapon wrote: > > Without so much as a stack trace there is nothing to chew on. > A useable vmcore would be better. > > Did you perhaps use kgdb with a mismatching kernel? > I don't remember, I just rebuild a new kernel and will provide more info if panic occurs again! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
usb mass storage problem
Hello :-) I have a problem with HP USB Pendrive 8GB memory - it works on Windows and Linux but it does not detect on FreeBSD 9.1(-RC3): ugen1.7: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
zfs v28 solaris compatibility
Hi. Is the FreeBSD v28 zfs fully compatible with solaris zfs ? I need to switch disks between servers, these disks are SAN disks, and it's about 20T of data. I don't want to lose them. I am aware that our zfs is compatible with Solaris, but I just want to be sure, like really really sure. Of course I can switch back at any moment, but only if the data won't become corrupted. Thanks. Eugene. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs v28 solaris compatibility
07.02.2013 14:16, Eugene M. Zheganin: Hi. Is the FreeBSD v28 zfs fully compatible with solaris zfs ? I need to switch disks between servers, these disks are SAN disks, and it's about 20T of data. I don't want to lose them. I am aware that our zfs is compatible with Solaris, but I just want to be sure, like really really sure. Of course I can switch back at any moment, but only if the data won't become corrupted. I think one simple way to test that is to create a replication stream for some filesystem with `zfs send` on first machine and check whether this stream is received correctly on the second machine. I'm mostly sure that you wouldn't lose your data, however Solaris is staying with ZFS v28 since the last release and FreeBSD is progressing slowly with Illumos. I'm pretty sure that 9-STABLE is already using ZFS feats and any pool created with current STABLE would not become writable for Solaris. -- Sphinx of black quartz, judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
NFSv4 + Kerberos permission denied
Hello, I've got a little problem with NFSv4 + Kerberos. I can do a mount with Kerberos with a valid ticket, but read-only. After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/ I can see: #klist: Feb 6 07:22:47 Feb 6 17:22:43 nfs/nfsserver@my.domain #/var/heimdal/kdc.log: 2013-02-06T07:28:26 TGS-REQ clientnfs@my.domain from IPv4:192.168.0.23 for nfs/nfsserver@my.domain tcpdump: 14:59:36.140272 IP nfsclient.61011 > 192.168.0.21.kerberos-sec: 14:59:36.142301 IP 192.168.0.21.kerberos-sec > nfsclient.61011: I got "Permission denied" message when I try to mkdir or rm. As a root mount and as a user mount (sysctl vfs.usermounts=1). With -sec=sys it works read-write, but with -sec=krb5 read-only.. my /etc/exports: V4: /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask 255.255.255.0 /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask 255.255.255.0 -maproot=root -alldirs tried with V4: / as well. Added all the principals needed. Tried also with full qualified domain names. SSH works fine with Kerberos Do I need rpcsec_gss.patch? (according to http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup) or can I make it work somehow else? I used FreeBSD-9.1-RELEASE-i386-disc1 and FreeBSD-10.0-CURRENT-i386-20130202-r246254-release -- Greets Janusz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ethtool-like utility for FreeBSD ?
Hi! There is a posting public about Intel ethernet adapters and their packets of death: http://blog.krisk.org/2013/02/packets-of-death.html Now, how can we test the EEPROM from FreeBSD, similar to the ethtool of Linux ? Thanks for any pointer! -- p...@opsec.eu+49 171 3101372 7 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs v28 solaris compatibility
If the pool is created as v28 in FreeBSD, then you will be able to import the pool into Solaris 10 or 11 without any issues. Just be sure to ignore all the "your pool is outdated messages", and do *NOT* upgrade your pool to ZFSv32 in Solaris. If you do that, you will not be able to import the pool in FreeBSD again. On Thu, Feb 7, 2013 at 4:16 AM, Eugene M. Zheganin wrote: > Hi. > > Is the FreeBSD v28 zfs fully compatible with solaris zfs ? I need to > switch disks between servers, these disks are SAN disks, and it's about > 20T of data. I don't want to lose them. I am aware that our zfs is > compatible with Solaris, but I just want to be sure, like really really > sure. Of course I can switch back at any moment, but only if the data > won't become corrupted. > > Thanks. > Eugene. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On Wednesday, February 06, 2013 1:24:57 am Mikhail T. wrote: > On 05.02.2013 23:38, Mikhail T. wrote: > > What happened between 6.x and 7.x? > Ok, what happened is that "device cpufreq" is now in GENERIC and the > ichss0 along with it. > > Setting > > set hint.ichss.0.disabled=1 > > on the loader prompt allows me to boot -- both my own kernel as well as > the 9.1-RELEASE from CD. Solved... Annoying beyond belief, but solved. I wonder if your system falls into this: /* * ICH2/3/4-M I/O Controller Hub is at bus 0, slot 1F, function 0. * E.g. see Section 6.1 "PCI Devices and Functions" and table 6.1 of * Intel(r) 82801BA I/O Controller Hub 2 (ICH2) and Intel(r) 82801BAM * I/O Controller Hub 2 Mobile (ICH2-M). * * TODO: add a quirk to disable if we see the 82815_MC along * with the 82801BA and revision < 5. */ ich_device = pci_find_bsf(0, 0x1f, 0); if (ich_device == NULL || pci_get_vendor(ich_device) != PCI_VENDOR_INTEL || (pci_get_device(ich_device) != PCI_DEV_82801BA && pci_get_device(ich_device) != PCI_DEV_82801CA && pci_get_device(ich_device) != PCI_DEV_82801DB)) return; Can you get pciconf -lc output? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On 07.02.2013 13:16, John Baldwin wrote: Can you get pciconf -lc output? Here: hostb0@pci0:0:0:0: class=0x06 card=0x chip=0x11308086 rev=0x02 hdr=0x00 cap 09[88] = vendor (length 4) Intel cap 15 version 1 cap 02[a0] = AGP 4x 2x 1x SBA disabled pcib1@pci0:0:1:0: class=0x060400 card=0x chip=0x11318086 rev=0x02 hdr=0x01 pcib2@pci0:0:30:0: class=0x060400 card=0x chip=0x24488086 rev=0x02 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0x chip=0x244c8086 rev=0x02 hdr=0x00 atapci0@pci0:0:31:1:class=0x010180 card=0x45418086 chip=0x244a8086 rev=0x02 hdr=0x00 uhci0@pci0:0:31:2: class=0x0c0300 card=0x45418086 chip=0x24428086 rev=0x02 hdr=0x00 vgapci0@pci0:1:0:0: class=0x03 card=0x00a31028 chip=0x4d461002 rev=0x00 hdr=0x00 cap 02[50] = AGP 4x 2x 1x SBA disabled cap 01[5c] = powerspec 2 supports D0 D1 D2 D3 current D0 pcm0@pci0:2:3:0:class=0x040100 card=0x00a31028 chip=0x1998125d rev=0x10 hdr=0x00 cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 xl0@pci0:2:6:0: class=0x02 card=0x645610b7 chip=0x605510b7 rev=0x10 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 none0@pci0:2:6:1: class=0x078000 card=0x615b10b7 chip=0x100710b7 rev=0x10 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D2 D3 current D0 cbb0@pci0:2:15:0: class=0x060700 card=0x00a31028 chip=0xac42104c rev=0x00 hdr=0x02 cap 01[a0] = powerspec 2 supports D0 D1 D2 D3 current D0 cbb1@pci0:2:15:1: class=0x060700 card=0x00a31028 chip=0xac42104c rev=0x00 hdr=0x02 cap 01[a0] = powerspec 2 supports D0 D1 D2 D3 current D0 none1@pci0:2:15:2: class=0x0c0010 card=0x00a31028 chip=0x8027104c rev=0x00 hdr=0x00 cap 01[44] = powerspec 2 supports D0 D2 D3 current D0 Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On Thursday, February 07, 2013 1:28:30 pm Mikhail T. wrote:
> On 07.02.2013 13:16, John Baldwin wrote:
> > Can you get pciconf -lc output?
> Here:
>
> hostb0@pci0:0:0:0: class=0x06 card=0x
> chip=0x11308086 rev=0x02 hdr=0x00
> cap 09[88] = vendor (length 4) Intel cap 15 version 1
> cap 02[a0] = AGP 4x 2x 1x SBA disabled
Looks like you have one of the systems the comment mentions. Try this patch
to see if ichss is disabled automatically for you:
Index: ichss.c
===
--- ichss.c (revision 246122)
+++ ichss.c (working copy)
@@ -67,7 +67,7 @@ struct ichss_softc {
#define PCI_DEV_82801BA0x244c /* ICH2M */
#define PCI_DEV_82801CA0x248c /* ICH3M */
#define PCI_DEV_82801DB0x24cc /* ICH4M */
-#define PCI_DEV_82815BA0x1130 /* Unsupported/buggy part */
+#define PCI_DEV_82815_MC 0x1130 /* Unsupported/buggy part */
/* PCI config registers for finding PMBASE and enabling SpeedStep. */
#define ICHSS_PMBASE_OFFSET0x40
@@ -155,9 +155,6 @@ ichss_identify(driver_t *driver, device_t parent)
* E.g. see Section 6.1 "PCI Devices and Functions" and table 6.1 of
* Intel(r) 82801BA I/O Controller Hub 2 (ICH2) and Intel(r) 82801BAM
* I/O Controller Hub 2 Mobile (ICH2-M).
-*
-* TODO: add a quirk to disable if we see the 82815_MC along
-* with the 82801BA and revision < 5.
*/
ich_device = pci_find_bsf(0, 0x1f, 0);
if (ich_device == NULL ||
@@ -167,6 +164,22 @@ ichss_identify(driver_t *driver, device_t parent)
pci_get_device(ich_device) != PCI_DEV_82801DB))
return;
+ /*
+* Certain systems with ICH2 and an Intel 82815_MC host bridge
+* where the host bridge's revision is < 5 lockup if SpeedStep
+* is used.
+*/
+ if (pci_get_device(ich_device) == PCI_DEV_82801BA) {
+ device_t hostb;
+
+ hostb = pci_find_bsf(0, 0, 0);
+ if (hostb != NULL &&
+ pci_get_vendor(hostb) == PCI_VENDOR_INTEL &&
+ pci_get_device(hostb) == PCI_DEV_82815_MC &&
+ pci_get_revid(hostb) < 5)
+ return;
+ }
+
/* Find the PMBASE register from our PCI config header. */
pmbase = pci_read_config(ich_device, ICHSS_PMBASE_OFFSET,
sizeof(pmbase));
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
CLANG and -fstack-protector
Hello, Does the -fstack-protector option work on CLANG 3.1 and 3.2? There is thread on FreeBSD forums about the stack protector and ports and I'm wondering if it's possible to use the -fstack-protector option with CLANG. http://forums.freebsd.org/showthread.php?t=36927 -Kimmo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CLANG and -fstack-protector
On 2013-02-07 20:42, Kimmo Paasiala wrote: Does the -fstack-protector option work on CLANG 3.1 and 3.2? Yes, it works with both clang and gcc. There is thread on FreeBSD forums about the stack protector and ports and I'm wondering if it's possible to use the -fstack-protector option with CLANG. http://forums.freebsd.org/showthread.php?t=36927 That thread seems to be full of confusion. :-) The base system is mostly built with -fstack-protector, except for the ia64, arm and mips arches, and for some specific cases where it is not necessary, or unwanted. Ports are largely independent of the base system, and their compilation flags are different from port to port. You could set -fstack-protector for your ports in either make.conf or ports.conf, if you wanted. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CLANG and -fstack-protector
Hi Kimmo, On Thu, Feb 07, 2013 at 10:06:49PM +0100, Dimitry Andric wrote: > On 2013-02-07 20:42, Kimmo Paasiala wrote: > > Does the -fstack-protector option work on CLANG 3.1 and 3.2? > > Yes, it works with both clang and gcc. > > > > There is thread on FreeBSD forums about the stack protector and ports > > and I'm wondering if it's possible to use the -fstack-protector option > > with CLANG. > > > > http://forums.freebsd.org/showthread.php?t=36927 > > That thread seems to be full of confusion. :-) The base system is mostly > built with -fstack-protector, except for the ia64, arm and mips arches, > and for some specific cases where it is not necessary, or unwanted. > > Ports are largely independent of the base system, and their compilation > flags are different from port to port. You could set -fstack-protector > for your ports in either make.conf or ports.conf, if you wanted. You can do this, it will work for most of the ports but some ports do not honor CFLAGS. If those ports happen to be linked againsst libraries that were compiled with -fstack-protector, you will get a missing symbol error. Well, to be honest, I don't remember enough details, they faded from my memory, I need to check this. So if you care about security enough, go for it! If you meet weird error like a missing "stack_chk_fail" symbol for some ports (lang/perl might be a candidate in my memory), then look at the PR below, it will probably solve your problem. Time has passed and I am interested in your feedback without the patch (and then with, if relevant). Basically the following PR contains a patch that waits for an exp run to be committed into the base system. This just turns libc.so into an ld script that pulls in libssp_nonshared.a. You just have to run "make all install" in src/lib/libc after applying it. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168010 I run it on my servers with -fstack-protector enabled for ports without any problem. Cheers! -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CLANG and -fstack-protector
On Thu, Feb 7, 2013 at 11:06 PM, Dimitry Andric wrote: > On 2013-02-07 20:42, Kimmo Paasiala wrote: >> >> Does the -fstack-protector option work on CLANG 3.1 and 3.2? > > > Yes, it works with both clang and gcc. > Good to know thank you! > >> There is thread on FreeBSD forums about the stack protector and ports >> and I'm wondering if it's possible to use the -fstack-protector option >> with CLANG. >> >> http://forums.freebsd.org/showthread.php?t=36927 > > > That thread seems to be full of confusion. :-) The base system is mostly > built with -fstack-protector, except for the ia64, arm and mips arches, > and for some specific cases where it is not necessary, or unwanted. I was aware of the base system being built with the stack protector on systems where it makes sense. > > Ports are largely independent of the base system, and their compilation > flags are different from port to port. You could set -fstack-protector > for your ports in either make.conf or ports.conf, if you wanted. Is there any work being done to provide an optional Makefile knob (WITH_STACK_PROTECTOR ?) to turn on -fstack-protector for ports that install network services (or other critical code)? I'd bet such feature would be popular. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ethtool-like utility for FreeBSD
> There is a posting public about Intel ethernet adapters and their > packets of death: > > http://blog.krisk.org/2013/02/packets-of-death.html > > Now, how can we test the EEPROM from FreeBSD, similar to the > ethtool of Linux ? There is no such tool. If you want to dump EEPROM contents, you can do so via one of the following ways for em(4) NICs or igb(4) NICs, as root: sysctl dev.XXX.Y.nvm=1(for recent/newer FreeBSD) sysctl dev.XXX.Y.debug=2 (for older FreeBSD) Where XXX is either "em" or "igb" depending on your NIC and Y is the interface number (e.g. 0 = em0, 1 = em1, etc.). After this, run "dmesg" and look at the output at the bottom. You will see something like this: Interface EEPROM Dump: Offset 0x 3000 d248 d022 0d30 f746 00f5 0x0010 0100 026b 108c 15d9 108c 8086 83df 0x0020 0008 2000 7e14 0048 1000 00d8 2700 0x0030 6cc9 3150 0722 040b 0984 c000 0706 Please see this page, search for "EEPROM", which documents a different bug pertaining the Intel 82573 where some EEPROMs were shipped with a power-saving bit enabled. Read it, do not skim it, because it explains the EEPROM dump endian difference WRT Linux ethtool vs. FreeBSD's driver: https://wiki.freebsd.org/BugBusting/Commonly_reported_issues There is no way on FreeBSD to change EEPROM contents. You will need to use Linux ethtool for this, or -- strongly recommended -- ask Intel for their DOS-based utility that fixes the "packet of death" setting in the EEPROM and follow their instructions. You can also ask your NIC (or motherboard) vendor and make it their problem (I'm willing to bet a lot of them aren't aware of it). To whom it may concern: these sysctls really need to be documented. They have sysctl -d descriptions but they need to be documented in man pages. I can write the man page updates if need be. Now, as far as the "packet of death" thing is concerned: cry me a river. Why is it people today think that hardware devices are immune to bugs? Is it because they're solid-state, thus give off the impression "there can be no problems?" I don't get it. *sighs* This sort of stuff seems to come as a surprise to younger generations or people who really do believe "chips never have problems". It seems to me that it stems from, as the generations have progressed, less and less people actually understanding how things work (all the way down to th bare metal). All this bloody abstracted programming and abstracted ideas do nothing but hide how things work. Really pisses me off. It might be more of a "wow, I didn't expect this to be a problem so low-level" surprise, which just further fuels my point -- people seem to think things Just Work(tm) today, when in my experience things today ***do not*** Just Work(tm). Most things are Extremely Broken(tm). Just be glad the issue is with an EEPROM setting and not silicon-level, otherwise you'd be flat out screwed barring driver-level workarounds. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFSv4 + Kerberos permission denied
Janusz Bulik wrote: > Hello, > I've got a little problem with NFSv4 + Kerberos. I can do a mount with > Kerberos with a valid ticket, but read-only. > After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/ > I can see: > > #klist: > Feb 6 07:22:47 Feb 6 17:22:43 nfs/nfsserver@my.domain > > #/var/heimdal/kdc.log: > 2013-02-06T07:28:26 TGS-REQ clientnfs@my.domain from IPv4:192.168.0.23 > for nfs/nfsserver@my.domain > > tcpdump: > 14:59:36.140272 IP nfsclient.61011 > 192.168.0.21.kerberos-sec: > 14:59:36.142301 IP 192.168.0.21.kerberos-sec > nfsclient.61011: > > I got "Permission denied" message when I try to mkdir or rm. As a root > mount and as a user mount (sysctl vfs.usermounts=1). > With -sec=sys it works read-write, but with -sec=krb5 read-only.. > Did you successfully read files under /mount_test? (I suspect no access would be closer to the truth than read-only, unless the non-root user with a valid TGT only has read access. Although I think it is technically possible to do so, typically "root" does not exist in a KDC as a user principal and, as such, "root" cannot do a kinit to get a TGT and that means "no access" to the kerberized mount point.) > my /etc/exports: > V4: /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 > /export_test -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask > 255.255.255.0 -maproot=root -alldirs > > tried with V4: / as well. > Added all the principals needed. > Tried also with full qualified domain names. > SSH works fine with Kerberos > > > Do I need rpcsec_gss.patch? (according to > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup) > or can I make it work somehow else? > > I used FreeBSD-9.1-RELEASE-i386-disc1 > and > FreeBSD-10.0-CURRENT-i386-20130202-r246254-release > Well, without the patch, the only kind of NFSv4 kerberized mount that will work is (NFSv3 is a different story): # sysctl vfs.usermount=1 - logged in as non-root user that has kinit'd and, therefore, has a valid TGT % mount -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test - then this user (or any other non-root user with a valid TGT) should be able to access /mount_test with whatever permissions the server has on the directories. (ie. If these users are supposed to create files/directories under /export_test, they will need write access to /export_test.) Note that "root" does not normally have any access to a kerberized mount point, since the KDC doesn't normally have a user principal for "root", as above. This mount will only work as long as the non-root user that did the mount holds a valid TGT. - To do an NFSv4 kerberized mount as root (which will keep working until unmount), you need to patch the system so that it can use a host based credential in the default keytab file as an initiator credential. If you use current/10.0 sources, I have a better patch to do this. It is at: http://people.freebsd.org/~rmacklem/rpcsec_gss-hostbased-initiator.patch After applying the patch, you need to build both the kernel and the gssd daemon from sources. You do not need to set the sysctl to the correct encryption type for the keytab entry to get it to work. After putting an entry in the client's /etc/keytab, rebooting the patched kernel with the rebuilt gssd daemon running on it, the mount looks like: # mount -t nfs -o nfsv4,sec=krb5,gssname=nfs nfsserver:/ /mount_test (Assuming that the keytab entry is for nfs/client-host.domain@YOUR_REALM.) This mount will still not give "root" access to the file system, for the same reasons as above, but can be done by "root" and doesn't need any valid TGT to keep working. At this time, there is no way to give "root" access to a kerberized mount unless you put a user principal for "root" (root@YOUR_REALM) in you KDC and then do a kinit when logged in as root. (This is not recommended from a security point of view.) If you can't get things to work: - try and use des-cbc-crc encryption for the keytab entries (you can try other ones after you have it working, so long as they result in an 8byte session key) - make sure the gssd is working on both client and server (it has to be running before the nfsd is started on the server) - check /var/log/messages for any messages from the gssd - check the log file on your KDC for hints of problems - capture packets of the mount and look at them in wireshark (use something like a "host" filter, so you get more than the NFS packets) Good luck with it, rick > -- > Greets > Janusz > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFSv4 + Kerberos permission denied
On 08/02/2013 01:05, Janusz Bulik wrote: > Hello, > I've got a little problem with NFSv4 + Kerberos. I can do a mount with > Kerberos with a valid ticket, but read-only. > After the mount -vvv -t nfs -o nfsv4,sec=krb5 nfsserver:/ /mount_test/ > I got "Permission denied" message when I try to mkdir or rm. As a root > mount and as a user mount (sysctl vfs.usermounts=1). > With -sec=sys it works read-write, but with -sec=krb5 read-only.. Am I right in supposing that you have never had this working? What you describe sounds symptomatic of nfsuserd not running - see nfsv4(4). sec=sys doesn't need nfsuserd to "work" but sec=krb5 does. If you mount with sec=krb5 and "ls -l /mount_test/" do you see in the listing the user and group names you expect, or just a bunch of numbers? The read-only access is probably what the filesystem permissions allow to "other" because, without nfsuserd, it can't map your kerberos principal to a uid. Of course, I could be wrong... -- John Marshall signature.asc Description: OpenPGP digital signature
Re: CLANG and -fstack-protector
On 7 February 2013 18:40, Kimmo Paasiala wrote: >> Ports are largely independent of the base system, and their compilation >> flags are different from port to port. You could set -fstack-protector >> for your ports in either make.conf or ports.conf, if you wanted. > > Is there any work being done to provide an optional Makefile knob > (WITH_STACK_PROTECTOR ?) to turn on -fstack-protector for ports that > install network services (or other critical code)? I'd bet such > feature would be popular. As far as I am aware no such feature exists. In any case it would be subject to the same problem of many ports ignoring CFLAGS and friends. -- Eitan Adler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
