http://localhost:901
Dear Sirs I install and configure xinetd.conf,but i can not load http://localhost:901 please help me. regards Pedram Dehghani System Administrator SG Co.
http://localhost:901
dear dan i cannot load the swatin http://localhost:901 i have give error : The connection was refused when attempting to contact localhost:901 please help me. regards Pedram Dehghani System Administrator SG Co.
Re: http://localhost:901
Original Message - From: root [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, December 23, 2002 12:26 PM Subject: http://localhost:901 dear dan i cannot load the swatin http://localhost:901 i have give error : The connection was refused when attempting to contact localhost:901 Read this: http://www.security-forums.com/forum/viewtopic.php?t=249 Then ask again when you have a clue. Thanks. Shaolin * This email has been checked by the altohiway e-Sweeper Service *
[PATCH] and question - net rpc shutdown
Hi!
This patch corrects a problem with the default comment for net rpc
shutdown.
(diff against 3.0)
My power off - problem persists because net rpc shutdown is similar to
InitiateSystemShutdown, which is not able to power off the computer. In
my research I've found out that powering off needs a Remote API call (if
my interpretations of the data on the wire are correct). Is there any
function in Samba which can send a remote API call?
Thanks
Willi
Index: utils/net.c
===
RCS file: /cvsroot/samba/source/utils/net.c,v
retrieving revision 1.43.2.8
diff -u -r1.43.2.8 net.c
--- utils/net.c 12 Nov 2002 23:20:49 - 1.43.2.8
+++ utils/net.c 23 Dec 2002 18:45:15 -
@@ -68,6 +68,7 @@
int opt_port = 0;
int opt_maxusers = -1;
char *opt_comment = ;
+BOOL opt_comment_specified = False;
int opt_flags = -1;
int opt_jobid = 0;
int opt_timeout = 0;
@@ -446,7 +447,7 @@
{myname, 'n', POPT_ARG_STRING, opt_requester_name},
{conf,'s', POPT_ARG_STRING, servicesf},
{server, 'S', POPT_ARG_STRING, opt_host},
- {comment, 'C', POPT_ARG_STRING, opt_comment},
+ {comment, 'C', POPT_ARG_STRING, opt_comment,'C'},
{maxusers,'M', POPT_ARG_INT,opt_maxusers},
{flags, 'F', POPT_ARG_INT,opt_flags},
{jobid, 'j', POPT_ARG_INT,opt_jobid},
@@ -487,6 +488,9 @@
*p = 0;
opt_password = p+1;
}
+ break;
+ case 'C':
+ opt_comment_specified = True;
break;
default:
d_printf(\nInvalid option %c (%d)\n,
(char)opt, opt);
Index: utils/net.h
===
RCS file: /cvsroot/samba/source/utils/net.h,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 net.h
--- utils/net.h 15 Jul 2002 10:35:23 - 1.7.2.1
+++ utils/net.h 23 Dec 2002 18:45:25 -
@@ -38,6 +38,7 @@
extern int opt_maxusers;
extern char *opt_comment;
+extern BOOL opt_comment_specified;
extern int opt_flags;
extern char *opt_comment;
Index: utils/net_rpc.c
===
RCS file: /cvsroot/samba/source/utils/net_rpc.c,v
retrieving revision 1.14.2.10
diff -u -r1.14.2.10 net_rpc.c
--- utils/net_rpc.c 20 Dec 2002 20:21:31 - 1.14.2.10
+++ utils/net_rpc.c 23 Dec 2002 18:45:34 -
@@ -1478,7 +1478,7 @@
if (force) {
flgs |= REG_FORCE_SHUTDOWN;
}
- if (opt_comment) {
+ if (opt_comment_specified) {
msg = opt_comment;
}
if (opt_timeout) {
Re: [PATCH] and question - net rpc shutdown
On Mon, 23 Dec 2002, Willi Mann wrote: Hi! This patch corrects a problem with the default comment for net rpc shutdown. (diff against 3.0) My power off - problem persists because net rpc shutdown is similar to InitiateSystemShutdown, which is not able to power off the computer. In my research I've found out that powering off needs a Remote API call (if my interpretations of the data on the wire are correct). Is there any function in Samba which can send a remote API call? Do you mean a RAP call? The net function does them. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
smbwrapper use of port 139 vs 445... Ok to force to 139?
My last known problem with smbwrapper on Linux is that sometimes hosts in a workgroup, or shares on a host, are not returned by the cli_Net*Enum() functions. On another list (debian.something), there is currently a discussion of the fact that using port 445 can cause this problem, and in fact, when I force the port to 139, the problem goes away. I'm not terribly familiar with the protocol differences between what's sent on port 139 and what's sent on port 445. *Specifically for the purposes of smbwrapper...* 1. Is there a reason not to force the port number to 139? 2. Is there any service provided on port 445, not provided on port 139, that's required for smbwrapper to return the correct data? 3. Are there any servers that don't provide port 139 service at all? 4. If #3 is yes, what about trying 139 and falling back to 445 rather than the current implementation which is the other way around? Thanks, Derrell
Re: smbwrapper use of port 139 vs 445... Ok to force to 139?
On Mon, Dec 23, 2002 at 02:51:08PM -0500, [EMAIL PROTECTED] wrote: My last known problem with smbwrapper on Linux is that sometimes hosts in a workgroup, or shares on a host, are not returned by the cli_Net*Enum() functions. On another list (debian.something), there is currently a discussion of the fact that using port 445 can cause this problem, and in fact, when I force the port to 139, the problem goes away. I'm not terribly familiar with the protocol differences between what's sent on port 139 and what's sent on port 445. *Specifically for the purposes of smbwrapper...* 1. Is there a reason not to force the port number to 139? 2. Is there any service provided on port 445, not provided on port 139, that's required for smbwrapper to return the correct data? 3. Are there any servers that don't provide port 139 service at all? 4. If #3 is yes, what about trying 139 and falling back to 445 rather than the current implementation which is the other way around? I understand the reason for using 445 as primary and falling back to 139 is that it's much more efficient (both on setup and during data transfer) than doing it the other way around. For the purposes of getting a browse list, connecting to port 139 is a must. There are ways to get the equivalent of a browse list via AD, but I don't think it's LDAP-only, so port 445 doesn't even do any good in this regard. For the actual enumeration of and connecting to shares, port 445 is likely to give some performance increase due to the lower protocol overhead. You can also configure newer Windows machines (XP at least) to *not* support NetBIOS at all, in which case they'll only be listening on port 445. OTOH, there are also plenty of older machines (NT4 and below) that are 139-only. Theoretically, it might be optimal to use port 139 to collect browse lists, and then use 445-else-139 for everything else. Barring that, I think 139-else-445 would be the best option. -- Steve Langasek postmodern programmer msg05067/pgp0.pgp Description: PGP signature
Re: smbwrapper use of port 139 vs 445... Ok to force to 139?
Steve Langasek [EMAIL PROTECTED] writes: For the purposes of getting a browse list, connecting to port 139 is a must. There are ways to get the equivalent of a browse list via AD, but I don't think it's LDAP-only, so port 445 doesn't even do any good in this regard. For the actual enumeration of and connecting to shares, port 445 is likely to give some performance increase due to the lower protocol overhead. You can also configure newer Windows machines (XP at least) to *not* support NetBIOS at all, in which case they'll only be listening on port 445. OTOH, there are also plenty of older machines (NT4 and below) that are 139-only. If an XP or other new machine is configured to not support port 139, and it becomes a master browser then how would one get the browse list? Theoretically, it might be optimal to use port 139 to collect browse lists, and then use 445-else-139 for everything else. Barring that, I think 139-else-445 would be the best option. This may be possible to do. The function where cli_initialize() and cli_connect() are called, is passed a server name and a share name. The share name seems to be IPC$ for every call I've seen into here, but is likely a real share name when opening a regular file. I have occasionally seen a server name of IPC$ as well. I suppose I could trace and determine which case is caused by which type of enumeration. Do you know offhand in which case(s) of server and share names I'm looking for a browse list? What if I do 139-else-445 if share is IPC$, and do 445-else-139 otherwise? Thanks, Derrell
Re: smbwrapper use of port 139 vs 445... Ok to force to 139?
On Mon, Dec 23, 2002 at 03:53:08PM -0500, [EMAIL PROTECTED] wrote: For the purposes of getting a browse list, connecting to port 139 is a must. There are ways to get the equivalent of a browse list via AD, but I don't think it's LDAP-only, so port 445 doesn't even do any good in this regard. For the actual enumeration of and connecting to shares, port 445 is likely to give some performance increase due to the lower protocol overhead. You can also configure newer Windows machines (XP at least) to *not* support NetBIOS at all, in which case they'll only be listening on port 445. OTOH, there are also plenty of older machines (NT4 and below) that are 139-only. If an XP or other new machine is configured to not support port 139, and it becomes a master browser then how would one get the browse list? If NetBIOS is disabled, the machine won't participate in browse elections, so it will never become the master browser. If NetBIOS is enabled, I believe that AD-aware machines are given a slight edge (in the form of the 'os level' option) in the browse election. Theoretically, it might be optimal to use port 139 to collect browse lists, and then use 445-else-139 for everything else. Barring that, I think 139-else-445 would be the best option. This may be possible to do. The function where cli_initialize() and cli_connect() are called, is passed a server name and a share name. The share name seems to be IPC$ for every call I've seen into here, but is likely a real share name when opening a regular file. I have occasionally seen a server name of IPC$ as well. I suppose I could trace and determine which case is caused by which type of enumeration. Do you know offhand in which case(s) of server and share names I'm looking for a browse list? What if I do 139-else-445 if share is IPC$, and do 445-else-139 otherwise? AFAIK, the share name will always be IPC$ for server enumeration, but I don't know what other side effects this approach might have. Certainly, the IPC$ share name would be used for other things which are not NetBIOS-dependent. -- Steve Langasek postmodern programmer msg05069/pgp0.pgp Description: PGP signature
Re: [PATCH] and question - net rpc shutdown
Richard Sharpe wrote: On Mon, 23 Dec 2002, Willi Mann wrote: Hi! This patch corrects a problem with the default comment for net rpc shutdown. (diff against 3.0) My power off - problem persists because net rpc shutdown is similar to InitiateSystemShutdown, which is not able to power off the computer. In my research I've found out that powering off needs a Remote API call (if my interpretations of the data on the wire are correct). Is there any function in Samba which can send a remote API call? Do you mean a RAP call? The net function does them. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com The function I'd need is the ExitWindowsEx winapi function. I don't think that rap provides what I need. If you want to help me, there are the links to the initial messages of my problem: http://lists.samba.org/pipermail/samba-technical/2002-December/041366.html http://lists.samba.org/pipermail/samba-technical/2002-December/041369.html One mistake is in that postings: The shutdown method provided in w2k works if the local and the remote user have the same usernames and passwords, it is not requrired that they are in the same domain. Thanks Willi Mann
Swat File
Dear Sir i can not find swat file in the /usr/local/sbin/ ,what can i do ? please help me. Regards Pedram Dehghani System Administrator SG Co.
