你的朋友傳統古早味府城花生糖-不黏牙新上市!!推薦星島網文章給你
§AªºªB¤Í¦W¦r
¡G
¶Ç²Î¥j¦¨ý©²«°ªá¥Í¿}-¤£ÂH¤ú·s¤W¥«!!
§AªºªB¤Í¤§¹q¶l¦a§}
¡G
sterl...@yahoo.com
µu°T¤º®e
¡G
¯S§O·PÁÂTVBS®É©|ª±®a²ï²ï¯S§O±ÀÂË
ºôÁÊ·s¥]¸Ë-¥R¤Àªí²{¥x ÆW¥»¤g¨ý
°e§¦Û¥Î¨â¬Û©y-¦n¦Y¤£ÂH¤ú¤£ªg¤â
²{¦b§K¹B¶O±M®×¹ê¬I¤¤~~ ~~
¤£¥Î¦hªá¿ú´N¥i¥H¦b®a¨É¨ü¬ü¹
½Ð«ö¤U±¡m³¡¸¨®æ¡n¶i¤Jºô¯¸ÁʶR /font
http://tw.myblog.yaho o.com/peanuts-tn4/guestbook
¤å³¹
¡G
/email_friend_act.asp
你的朋友保護腳的專家-不臭博士襪-不滿意就退款!!推薦星島網文章給你
§AªºªB¤Í¦W¦r ¡G «OÅ@¸}ªº±M®a-¤£¯ä³Õ¤hÄû-¤£º¡·N´N°h´Ú!! §AªºªB¤Í¤§¹q¶l¦a§} ¡G sterl...@yahoo.com µu°T¤º®e ¡G ®Ú¾Ú¤é¥»±M®a¬ã¨sÅã¥Ü ¸}¬O¤Hªº²Ä¤GÓ¤ßŦ ·R±¤§Aªº¸}-«OÅ @§Aªº¸} ¤£¥Î¶Q¬À¬À-¥un120¤¸ ¦n¥Î«K©y¤S«OÃÒ¤£·|¯ä¯ä §ÚÌ MIT«~½è«OÃÒ»P¤é¥»¦P¯Å ÅwªïÁʶR¸Õ¬ï-¤£º¡·N«OÃÒ°h´Ú ½Ð«ö¤U±³¡¸¨® æºô§}¶i¤JÁʶR http://tw.myblog.yahoo.com/sox -mitgood6 goodmit omabrceme07 769puzkts4682kupe13h14eb09qr9fo7l7n0i083g5k9gliq2chip52mnaerxqc898b15am44f8a4 l6rpd5jc6gnbb22lrzjwizbkba5igwkswt1detu0h3o ¤å³¹ ¡G /email_friend_act.asp
Re: usermod: lock/unlock local password
On Tue, Sep 11, 2012 at 06:24:04PM +0200, Antoine Jacoutot wrote:
On Tue, Sep 11, 2012 at 04:46:57PM +0200, Antoine Jacoutot wrote:
On Mon, Sep 10, 2012 at 05:01:13PM +0200, Antoine Jacoutot wrote:
Hi.
This diff adds 2 new options to usermod(8):
-U to unlock a user's password
-Z to lock a user's password
In effect locking/unlocking the password means to add a '!' in front of
the encrypted entry in master.passwd.
Note that this disable the _password_ not the account of course (you
could still connect using ssh+key for e.g.).
That said, I have some use for it and would like to be able to have this
if at all possible.
Behavior is basically the same as Linux's usermod(8) except that I am
using -Z for locking the password (-Z is for SElinux in Linux land and
-L is used instead but we use it ourselves for the login class).
Ok new diff that does something slightly different.
Instead of putting a '!' in front of the password (which confused people),
lock/unlock means appending/removing a dash to the user's login shell.
While this is non standard behavior (but as I mentionned in a previous
mail, usermod(8) is already not standard accross unices) I think it is
better because:
- account is locked, period (no local login, no remote login -- no surprise
for tedu ;-) )
- no values are touched
(e.g. one could disable an account by using 'usermod -e 1' but when he
wants to re-enable the account he'll be forced to change the expiration
time)
New diff which also put a '*' in front of the encrypted password; i.e. both
pre and post-auth become locked (req. by Theo).
With some man page tweak from jmc.
Anyone?
Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.90
diff -u -r1.90 user.c
--- user.c29 Jan 2012 08:38:54 - 1.90
+++ user.c11 Sep 2012 16:20:11 -
@@ -100,7 +100,9 @@
F_UID = 0x0400,
F_USERNAME = 0x0800,
F_CLASS = 0x1000,
- F_SETSECGROUP = 0x4000
+ F_SETSECGROUP = 0x4000,
+ F_ACCTLOCK = 0x8000,
+ F_ACCTUNLOCK= 0x1
};
#define CONFFILE /etc/usermgmt.conf
@@ -1339,11 +1341,17 @@
struct group*grp;
const char *homedir;
charbuf[LINE_MAX];
+ characctlock_str[] = -;
+ charpwlock_str[] = *;
+ charpw_len[PasswordLength + 1];
+ charshell_len[MaxShellNameLen];
size_t colonc, loginc;
size_t cc;
FILE*master;
charnewdir[MaxFileNameLen];
char*colon;
+ char*pw_tmp = NULL;
+ char*shell_tmp = NULL;
int len;
int masterfd;
int ptmpfd;
@@ -1359,6 +1367,10 @@
if (!is_local(login_name, _PATH_MASTERPASSWD)) {
errx(EXIT_FAILURE, User `%s' must be a local user,
login_name);
}
+ if (up != NULL) {
+ if ((up-u_flags (F_ACCTLOCK | F_ACCTUNLOCK)) (pwp-pw_uid
== 0))
+ errx(EXIT_FAILURE, (un)locking is not supported for
the `%s' account, pwp-pw_name);
+ }
/* keep dir name in case we need it for '-m' */
homedir = pwp-pw_dir;
@@ -1410,6 +1422,48 @@
pwp-pw_passwd = up-u_password;
}
}
+ if (up-u_flags F_ACCTLOCK) {
+ /* lock the account */
+ if (strncmp(pwp-pw_shell+strlen(pwp-pw_shell) - 1,
acctlock_str+strlen(acctlock_str) - 1, sizeof(acctlock_str) - 1) != 0) {
+ shell_tmp = malloc(strlen(pwp-pw_shell) +
sizeof(acctlock_str));
+ if (shell_tmp == NULL) {
+ (void) close(ptmpfd);
+ pw_abort();
+ errx(EXIT_FAILURE, account lock:
cannot allocate memory);
+ }
+ strlcpy(shell_tmp, pwp-pw_shell,
sizeof(shell_len));
+ strlcat(shell_tmp, acctlock_str,
sizeof(shell_len));
+ pwp-pw_shell = shell_tmp;
+ }
+ /* lock the password */
+ if (strncmp(pwp-pw_passwd, pwlock_str,
sizeof(pwlock_str)-1) != 0) {
+ pw_tmp = malloc(strlen(pwp-pw_passwd) +
sizeof(pwlock_str));
+ if (pw_tmp == NULL) {
+ (void) close(ptmpfd);
+ pw_abort();
+ errx(EXIT_FAILURE, password lock:
cannot allocate memory);
+ }
+
Re: usermod: lock/unlock local password
On Fri, Sep 14, 2012 at 08:59, Antoine Jacoutot wrote:
Anyone?
+/* lock the account */
+if (strncmp(pwp-pw_shell+strlen(pwp-pw_shell) - 1,
acctlock_str+strlen(acctlock_str) - 1, sizeof(acctlock_str) - 1) != 0) {
This looks like a horifically complicated way to check if the last
character is -. Can we simplify some?
Re: Use ACPI to detect secondary PCI root segments on x86
Hi, On Thu, Sep 13, 2012 at 11:00:12PM +0200, Mark Kettenis wrote: However, there might be a different solution: We could track attached busses (not just host bridge busses but all busses) in the pci code (or via MD code and hooks but I think that would be a generic thing) and do nothing in pciattach if a bus is discovered for the second time. With this MD code could use whatever methods it wants to detect otherwise undiscovered host bridges. Possible methods might be magic numbers, hints from ACPI or even a linear scan of all possible bus numbers. Does this sound like a possible solution? It actually got me thinking about proper bus number resource accounting again. Something that's needed for properly hot-plugging pci busses. Below is a diff that does this. With that code, your acpi code can just try to grab the bus number using extent_alloc_region() and only attach a bus if that succeeds. Nice idea! However, I have some doubts about the implementation. In particular you don't pass sc_busex down through bridge devices. This is ok as long as all busses that we _discover_ downstream of that bridge are in fact _physically_ dowstream of that bridge, too. In this case the bus range of the bridge (PPB_BUSINFO_SECONDARY..PPB_BUSINFO_SUBORDINATE) covers all busses. However, host bridges that are handled e.g. in arch/i386/pci/pchb.c can appear downstream of another bridge but use bus numbers that are outside of the upstream bridge's bus number range. The easiest solution would probably be, to make the pcibus_ex an MI thing, i.e. define and allocate it globally in dev/pci/pci.c. regardsChristian
Re: tcp ping
On 2012/09/13 13:54, Matthew Dempsky wrote: On Thu, Sep 13, 2012 at 12:02 PM, Ted Unangst t...@tedunangst.com wrote: This adds a -T portnum option to ping. I haven't polished the output because I'm not sure if this is desirable or not, but I found it useful. If it's not a hell no, never in base I can finish it up some. Is there precedent for having TCP-based ping in any other OS's ping(1) utility? It seems like adding a separate tcpping(1) utility and leaving ping(1) for ICMP would be more appropriate. traceroute allows setting the protocol (though this doesn't work for tcp yet ;) so I think it would make some sort of sense to do this in ping/ping6.
Re: tcp ping
On 14 September 2012 11:39, Stuart Henderson s...@spacehopper.org wrote: On 2012/09/13 13:54, Matthew Dempsky wrote: On Thu, Sep 13, 2012 at 12:02 PM, Ted Unangst t...@tedunangst.com wrote: This adds a -T portnum option to ping. I haven't polished the output because I'm not sure if this is desirable or not, but I found it useful. If it's not a hell no, never in base I can finish it up some. Is there precedent for having TCP-based ping in any other OS's ping(1) utility? It seems like adding a separate tcpping(1) utility and leaving ping(1) for ICMP would be more appropriate. traceroute allows setting the protocol (though this doesn't work for tcp yet ;) so I think it would make some sort of sense to do this in ping/ping6. I agree, if this is getting in, it should be on ping :).
Re: Use ACPI to detect secondary PCI root segments on x86
Hi,
On Fri, Sep 14, 2012 at 10:31:05AM +0200, Christian Ehrhardt wrote:
On Thu, Sep 13, 2012 at 11:00:12PM +0200, Mark Kettenis wrote:
However, there might be a different solution:
We could track attached busses (not just host bridge busses but all
busses)
in the pci code (or via MD code and hooks but I think that would be a
generic thing) and do nothing in pciattach if a bus is discovered for
the second time.
With this MD code could use whatever methods it wants to detect otherwise
undiscovered host bridges. Possible methods might be magic numbers, hints
from ACPI or even a linear scan of all possible bus numbers.
Does this sound like a possible solution?
It actually got me thinking about proper bus number resource
accounting again. Something that's needed for properly hot-plugging
pci busses. Below is a diff that does this.
With that code, your acpi code can just try to grab the bus number
using extent_alloc_region() and only attach a bus if that succeeds.
Nice idea!
However, I have some doubts about the implementation. In particular
you don't pass sc_busex down through bridge devices. This is ok as long
as all busses that we _discover_ downstream of that bridge are in fact
_physically_ dowstream of that bridge, too. In this case the bus range
of the bridge (PPB_BUSINFO_SECONDARY..PPB_BUSINFO_SUBORDINATE) covers
all busses.
However, host bridges that are handled e.g. in arch/i386/pci/pchb.c
can appear downstream of another bridge but use bus numbers that are
outside of the upstream bridge's bus number range.
The easiest solution would probably be, to make the pcibus_ex an MI
thing, i.e. define and allocate it globally in dev/pci/pci.c.
Below is the suggestion for an updated patch that follows this strategy.
I'm not entirely confident about the i386/pchb.c part of the patch, though.
People that own such hardware would have to verify that all their hardware
is discovered properly.
This code tries to catch theoretical cases where we have two ACPI
discovered host bridges and the one listed _first_ in ACPI is discoverable
from the second one via PCI mechanisms (but not vice versa). In this case
the host bridge code and not the ACPI code must detect that the second
host bridge has already been attached. However, this assumes that host
bridges never use a bus numbers that are within the bus range of their
upstream bridge.
regards Christian
Index: arch/i386/i386/mainbus.c
===
RCS file: /cvs/src/sys/arch/i386/i386/mainbus.c,v
retrieving revision 1.48
diff -u -r1.48 mainbus.c
--- arch/i386/i386/mainbus.c3 Nov 2010 10:15:23 - 1.48
+++ arch/i386/i386/mainbus.c14 Sep 2012 09:48:34 -
@@ -244,6 +244,9 @@
mba.mba_pba.pba_domain = pci_ndomains++;
mba.mba_pba.pba_bus = 0;
config_found(self, mba.mba_pba, mainbus_print);
+#if NACPI 0
+ acpi_pciroots_attach(self, mba.mba_pba, mainbus_print);
+#endif
}
#endif
Index: arch/i386/pci/pchb.c
===
RCS file: /cvs/src/sys/arch/i386/pci/pchb.c,v
retrieving revision 1.85
diff -u -r1.85 pchb.c
--- arch/i386/pci/pchb.c31 Aug 2010 17:13:46 - 1.85
+++ arch/i386/pci/pchb.c14 Sep 2012 09:48:34 -
@@ -403,6 +421,8 @@
if (doattach == 0)
return;
+ if (extent_alloc_region(pcibus_ex, pbnum, 1, EX_NOWAIT) != 0)
+ return;
bzero(pba, sizeof(pba));
pba.pba_busname = pci;
@@ -505,6 +525,8 @@
pba.pba_domain = pa-pa_domain;
pba.pba_bus = AMD64HT_LDT_SEC_BUS_NUM(bus);
pba.pba_pc = pa-pa_pc;
- config_found(self, pba, pchb_print);
+ if (extent_alloc_region(pcibus_ex, pba.pba_bus, 1, EX_NOWAIT)
+ == 0)
+ config_found(self, pba, pchb_print);
}
}
Index: arch/i386/pci/pci_machdep.c
===
RCS file: /cvs/src/sys/arch/i386/pci/pci_machdep.c,v
retrieving revision 1.68
diff -u -r1.68 pci_machdep.c
--- arch/i386/pci/pci_machdep.c 4 Dec 2011 20:08:09 - 1.68
+++ arch/i386/pci/pci_machdep.c 14 Sep 2012 09:48:34 -
@@ -921,6 +921,11 @@
extent_alloc_region(pcimem_ex, IOM_BEGIN, IOM_SIZE,
EX_CONFLICTOK | EX_NOWAIT);
}
+
+ if (pcibus_ex == NULL) {
+ pcibus_ex = extent_create(pcibus, 0, 0xff, M_DEVBUF,
+ NULL, 0, EX_NOWAIT);
+ }
}
#include acpi.h
Index: arch/i386/pci/pci_machdep.h
===
RCS file: /cvs/src/sys/arch/i386/pci/pci_machdep.h,v
retrieving revision 1.23
diff -u -r1.23 pci_machdep.h
--- arch/i386/pci/pci_machdep.h 10 Oct 2011 19:42:36 - 1.23
+++
missing description for strtod(3)
strtod also accepts NAN, NAN(xxx) and INF as legal values. Missing part taken from FreeBSD, except that the documentation ommited INF and mentioned only INFINITY. Index: strtod.3 === RCS file: /cvs/src/lib/libc/stdlib/strtod.3,v retrieving revision 1.14 diff -u -p -r1.14 strtod.3 --- strtod.313 Sep 2008 22:48:45 - 1.14 +++ strtod.314 Sep 2012 10:10:39 - @@ -87,7 +87,32 @@ or .Sq e , followed by an optional plus or minus sign, followed by a sequence of digits. .Pp -Leading whitespace characters in the string (as defined by the +Alternatively, if the portion of the string following the optional +plus or minus sign begins with +.Dq INF +or +.Dq NAN , +ignoring case, it is interpreted as an infinity or a quiet \*(Na, +respectively. +The syntax +.Dq Xo Pf NAN( Ar s ) Xc , +where +.Ar s +is an alphanumeric string, produces the same value as the call +.Fo nan +.Qq Ar s Ns +.Fc +(respectively, +.Fo nanf +.Qq Ar s Ns +.Fc +and +.Fo nanl +.Qq Ar s Ns +.Fc . ) +.Pp +In any of the above cases, leading whitespace characters in the +string (as defined by the .Xr isspace 3 function) are skipped. .Sh RETURN VALUES -- Michal Mazurek
Re: Use ACPI to detect secondary PCI root segments on x86
Christian Ehrhardt ehrhardt at genua.de writes: However, host bridges that are handled e.g. in arch/i386/pci/pchb.c can appear downstream of another bridge but use bus numbers that are outside of the upstream bridge's bus number range. What I understood from the discussion, there is a possibility of kinda multi-path within pci discovery. Right? No being a pci guru, I did some work on azalia(4) in the past. azalia(4) also need to deal with multi-path, but for signal flow: audio codec has numerous one-to-one, one-to-many or many-to-many connected nodes (dacs, adcs, mixers) which signal should pass through. Some signal paths are dead-end, some aren't. azalia(4) uses so called traversing mechanism do detect right signal flow and mark dead nodes as dead. So the result of traversing is a tree-like structure (I'm simplifying here) containing right signal path. That's the principle: do traverse first, than operate. pci bus structure is also tree-like and maybe it is better to do traversing first, remove duplicated nodes and than do actual device attachments. Doing traversing may involve different bus discovery methods (bios, acpi etc). Just a raw idea.
missing argument in vaccess.9
vaccess()' first argument is type. Index: vaccess.9 === RCS file: /cvs/src/share/man/man9/vaccess.9,v retrieving revision 1.7 diff -u -p -r1.7 vaccess.9 --- vaccess.9 19 Sep 2010 13:17:25 - 1.7 +++ vaccess.9 14 Sep 2012 17:13:58 - @@ -36,6 +36,7 @@ .Fd #include sys/vnode.h .Ft int .Fo vaccess +.Fa enum vtype type .Fa mode_t file_mode .Fa uid_t uid .Fa gid_t gid @@ -50,6 +51,7 @@ function checks if the credentials descr are sufficient to perform the operation described by .Fa acc_mode , based on the +.Fa type , .Fa file_mode , .Fa uid , and -- Michal Mazurek
Re: Use ACPI to detect secondary PCI root segments on x86
Date: Fri, 14 Sep 2012 10:31:05 +0200 From: Christian Ehrhardt ehrha...@genua.de Hi, On Thu, Sep 13, 2012 at 11:00:12PM +0200, Mark Kettenis wrote: However, there might be a different solution: We could track attached busses (not just host bridge busses but all busses) in the pci code (or via MD code and hooks but I think that would be a generic thing) and do nothing in pciattach if a bus is discovered for the second time. With this MD code could use whatever methods it wants to detect otherwise undiscovered host bridges. Possible methods might be magic numbers, hints from ACPI or even a linear scan of all possible bus numbers. Does this sound like a possible solution? It actually got me thinking about proper bus number resource accounting again. Something that's needed for properly hot-plugging pci busses. Below is a diff that does this. With that code, your acpi code can just try to grab the bus number using extent_alloc_region() and only attach a bus if that succeeds. Nice idea! However, I have some doubts about the implementation. In particular you don't pass sc_busex down through bridge devices. This is ok as long as all busses that we _discover_ downstream of that bridge are in fact _physically_ dowstream of that bridge, too. In this case the bus range of the bridge (PPB_BUSINFO_SECONDARY..PPB_BUSINFO_SUBORDINATE) covers all busses. Indeed. At some point I'll probably add extents for the secondary busses as well, but they're not necessary for what you need. However, host bridges that are handled e.g. in arch/i386/pci/pchb.c can appear downstream of another bridge but use bus numbers that are outside of the upstream bridge's bus number range. Right. That's easy to fix though. See the attached diff. The easiest solution would probably be, to make the pcibus_ex an MI thing, i.e. define and allocate it globally in dev/pci/pci.c. No that's not acceptable. On real server hardware (not the glorified PCs you're hacking on ;)) there are multiple, fully independent, PCI host bridges serving independent PCI domains that each have the full range of bus numbers available to them. Having a single global extent obviously wouldn't work there. Let me know if this works for you. Index: pchb.c === RCS file: /cvs/src/sys/arch/i386/pci/pchb.c,v retrieving revision 1.85 diff -u -p -r1.85 pchb.c --- pchb.c 31 Aug 2010 17:13:46 - 1.85 +++ pchb.c 14 Sep 2012 17:45:46 - @@ -409,6 +409,7 @@ pchbattach(struct device *parent, struct pba.pba_iot = pa-pa_iot; pba.pba_memt = pa-pa_memt; pba.pba_dmat = pa-pa_dmat; + pba.pba_busex = pa-pa_busex; pba.pba_domain = pa-pa_domain; pba.pba_bus = pbnum; pba.pba_pc = pa-pa_pc; @@ -502,6 +503,7 @@ pchb_amd64ht_attach(struct device *self, pba.pba_iot = pa-pa_iot; pba.pba_memt = pa-pa_memt; pba.pba_dmat = pa-pa_dmat; + pba.pba_busex = pa-pa_busex; pba.pba_domain = pa-pa_domain; pba.pba_bus = AMD64HT_LDT_SEC_BUS_NUM(bus); pba.pba_pc = pa-pa_pc;
mention vdrop in vhold.9
Taken from FreeBSD. Index: Makefile === RCS file: /cvs/src/share/man/man9/Makefile,v retrieving revision 1.171 diff -u -p -r1.171 Makefile --- Makefile21 Jun 2012 18:02:21 - 1.171 +++ Makefile14 Sep 2012 18:06:46 - @@ -373,5 +373,6 @@ MLINKS+=VOP_LOOKUP.9 VOP_ABORTOP.9 VOP_L MLINKS+=workq_add_task.9 workq_create.9 \ workq_add_task.9 workq_queue_task.9 \ workq_add_task.9 workq_destroy.9 +MLINKS+=vhold.9 vdrop.9 .include bsd.prog.mk Index: vhold.9 === RCS file: /cvs/src/share/man/man9/vhold.9,v retrieving revision 1.6 diff -u -p -r1.6 vhold.9 --- vhold.9 15 Dec 2009 07:34:58 - 1.6 +++ vhold.9 14 Sep 2012 18:06:46 - @@ -38,6 +38,8 @@ .Fd #include sys/vnode.h .Ft void .Fn vhold struct vnode *vp +.Ft void +.Fn vdrop struct vnode *vp .Sh DESCRIPTION The .Fn vhold @@ -50,6 +52,16 @@ and .Va v_usecount are both zero, it will be removed from the free list and added to the vnode hold list. +.Pp +The +.Fn vdrop +function decrements the +.Va v_holdcnt +of the vnode. +If the holdcount is less than or equal to zero prior to calling +.Fn vdrop , +the system will panic. +If the vnode is no longer referenced, it will be freed. .Sh SEE ALSO .Xr vnode 9 .Sh AUTHORS -- Michal Mazurek
Testing. Please ignore.
This is a Test. Please disregard.
