Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-25 Thread Tom Collins
On Jun 25, 2004, at 9:23 AM, Paul Theodoropoulos wrote:
sooo - nobody knows where the directory 'incrementer' lives? Tom? i 
have no fix? i'm stuck with going from

/u1/domains/0/abc.com   to
/u1/domains/5/def.com
?? no way to get the system to resume creating new domains under the 
more logical /u1/domains/1/def.com?

i mean, yeah - i can live with it. it's not affecting actual 
functionality.
That's one area of code that I haven't looked at.  I really don't know 
how vpopmail decides where to put new domains.

--
Tom Collins  -  [EMAIL PROTECTED]
QmailAdmin: http://qmailadmin.sf.net/  Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/


Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-25 Thread Paul Theodoropoulos
indeed, but i can't take that risk without knowing the specific details for 
sure. this is a production system with thousands of customers.

would Bill Shupp possibly know?
At 10:00 AM 6/25/2004, Ken Jones wrote:
It might be as simple as changing the two 5 entries to 0
which from your listing below looks like the level_index0 and the_dir columns
Ken Jones
On Friday 25 June 2004 11:23 am, Paul Theodoropoulos wrote:
 sooo - nobody knows where the directory 'incrementer' lives? Tom? i have no
 fix? i'm stuck with going from

 /u1/domains/0/abc.com   to
 /u1/domains/5/def.com

 ?? no way to get the system to resume creating new domains under the more
 logical /u1/domains/1/def.com?

 i mean, yeah - i can live with it. it's not affecting actual functionality.

 At 12:16 PM 6/23/2004, Paul Theodoropoulos wrote:
 well, now it's incremented up to '5'. eesh. what i've found in perusing
 the mysql backend db, is the following:
 
 mysql select * from dir_control where domain = 'dom_89';
 ++---+---+---+--+-
 -+--+++++-
 ---++--+--+--+
 -+
 
 | domain | cur_users | level_cur | level_max | level_start0 | level_start1
 | level_start2 | level_end0 | level_end1 | level_end2 | level_mod0 |
 
 level_mod1 | level_mod2 | level_index0 | level_index1 | level_index2 |
 the_dir |
 ++---+---+---+--+-
 -+--+++++-
 ---++--+--+--+
 -+
 
 | dom_89 |   201 | 0 | 3 |0 |0
 |0 | 61 | 61 | 61 |  0
 |  2 |  4 |5 |0 |0 |
 
 5   |
 ++---+---+---+--+-
 -+--+++++-
 ---++--+--+--+
 -+ 1 row in set (0.00 sec)
 
 
 there is no domain dom_89, which suggests to me this may be the 'master
 control' for what overflow subdirectory is to be used - it's the only
 record that has '5' for the value 'the_dir', and '89' is the vpopmail
  uid/gid.
 
 however, i'm reluctant to make changes to the record, for fear of, well,
 duh - completely destroying my setup with one bad keystroke.
 
 so, if anyone can confirm my speculations, and suggest how to fix it
 (that's right, i've never inserted data manually into a table!), i'd
 appreciate the help.

 Paul Theodoropoulos
 http://www.anastrophe.com
Paul Theodoropoulos
http://www.anastrophe.com



Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-25 Thread Ken Jones
On Friday 25 June 2004 12:07 pm, Paul Theodoropoulos wrote:
 indeed, but i can't take that risk without knowing the specific details for
 sure. this is a production system with thousands of customers.

 would Bill Shupp possibly know?

I wrote the code. Bill might know.

What you can do is keep the original data, then update and add a domain.
If it doesn't work, put the old data back. It only is used when adding domains
not users.

Also, if you have a different machine for testing, add domains until 
it starts adding to the /0/ directory, and use those settings.

Ken


 At 10:00 AM 6/25/2004, Ken Jones wrote:
 It might be as simple as changing the two 5 entries to 0
 which from your listing below looks like the level_index0 and the_dir
  columns
 
 Ken Jones
 
 On Friday 25 June 2004 11:23 am, Paul Theodoropoulos wrote:
   sooo - nobody knows where the directory 'incrementer' lives? Tom? i
   have no fix? i'm stuck with going from
  
   /u1/domains/0/abc.com   to
   /u1/domains/5/def.com
  
   ?? no way to get the system to resume creating new domains under the
   more logical /u1/domains/1/def.com?
  
   i mean, yeah - i can live with it. it's not affecting actual
   functionality.
  
   At 12:16 PM 6/23/2004, Paul Theodoropoulos wrote:
   well, now it's incremented up to '5'. eesh. what i've found in
perusing the mysql backend db, is the following:
   
   mysql select * from dir_control where domain = 'dom_89';
   ++---+---+---+--+-
   
-+--+++++
   -
---++--+--+--+---
   - -+
   
   | domain | cur_users | level_cur | level_max | level_start0 |
   | level_start1 level_start2 | level_end0 | level_end1 | level_end2 |
   | level_mod0 |
   
   level_mod1 | level_mod2 | level_index0 | level_index1 | level_index2 |
   the_dir |
   ++---+---+---+--+-
   
-+--+++++
   -
---++--+--+--+---
   - -+
   
   | dom_89 |   201 | 0 | 3 |0 | 
   |   0 0 | 61 | 61 | 61 |  0 2 |   
   |   4 |5 |0 |0 |
   
   5   |
   ++---+---+---+--+-
   
-+--+++++
   -
---++--+--+--+---
   - -+ 1 row in set (0.00 sec)
   
   
   there is no domain dom_89, which suggests to me this may be the
'master control' for what overflow subdirectory is to be used - it's
the only record that has '5' for the value 'the_dir', and '89' is the
vpopmail uid/gid.
   
   however, i'm reluctant to make changes to the record, for fear of,
well, duh - completely destroying my setup with one bad keystroke.
   
   so, if anyone can confirm my speculations, and suggest how to fix it
   (that's right, i've never inserted data manually into a table!), i'd
   appreciate the help.
  
   Paul Theodoropoulos
   http://www.anastrophe.com

 Paul Theodoropoulos
 http://www.anastrophe.com


Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-25 Thread Paul Theodoropoulos
At 12:33 PM 6/25/2004, Ken Jones wrote:
What you can do is keep the original data, then update and add a domain.
If it doesn't work, put the old data back. It only is used when adding domains
not users.
thanks. so my speculation that the 'dom_89' user is sort of a 
'master'  field for such things is correct?

i'll give this a try. and i'll be using phpMyadmin - thanks to the guys for 
the various suggestions for running it. (i'm doing two layers of security - 
first a .htaccess allowing only my home machine, and, when i'm not using 
phpmyadmin - which is most of the time - i just chmod  the phpmyadmin 
directory. that's about as secure as you can get, i'd say!)

   there is no domain dom_89, which suggests to me this may be the
'master control' for what overflow subdirectory is to be used - it's
the only record that has '5' for the value 'the_dir', and '89' is the
vpopmail uid/gid.
   
   however, i'm reluctant to make changes to the record, for fear of,
well, duh - completely destroying my setup with one bad keystroke.
   
   so, if anyone can confirm my speculations, and suggest how to fix it
   (that's right, i've never inserted data manually into a table!), i'd
   appreciate the help.
  
   Paul Theodoropoulos
   http://www.anastrophe.com

 Paul Theodoropoulos
 http://www.anastrophe.com
Paul Theodoropoulos
http://www.anastrophe.com



Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-25 Thread Ken Jones
On Friday 25 June 2004 02:40 pm, Paul Theodoropoulos wrote:
 At 12:33 PM 6/25/2004, Ken Jones wrote:
 What you can do is keep the original data, then update and add a domain.
 If it doesn't work, put the old data back. It only is used when adding
  domains not users.

 thanks. so my speculation that the 'dom_89' user is sort of a
 'master'  field for such things is correct?

Yep! It controls just the domain directory layout.
dom_89 is short for domain_directory_layout_user_id_89
since 89 was reserved for vpopmail by one of the *nix distributions .


 i'll give this a try. and i'll be using phpMyadmin - thanks to the guys for
 the various suggestions for running it. (i'm doing two layers of security -
 first a .htaccess allowing only my home machine, and, when i'm not using
 phpmyadmin - which is most of the time - i just chmod  the phpmyadmin
 directory. that's about as secure as you can get, i'd say!)

 there is no domain dom_89, which suggests to me this may be the
  'master control' for what overflow subdirectory is to be used -
  it's the only record that has '5' for the value 'the_dir', and
  '89' is the vpopmail uid/gid.
 
 however, i'm reluctant to make changes to the record, for fear of,
  well, duh - completely destroying my setup with one bad
  keystroke.
 
 so, if anyone can confirm my speculations, and suggest how to fix
  it (that's right, i've never inserted data manually into a
  table!), i'd appreciate the help.

 Paul Theodoropoulos
 http://www.anastrophe.com
  
   Paul Theodoropoulos
   http://www.anastrophe.com

 Paul Theodoropoulos
 http://www.anastrophe.com


Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-25 Thread Jeremy Kitchen
On Friday 25 June 2004 03:41 pm, Ken Jones wrote:
 On Friday 25 June 2004 02:40 pm, Paul Theodoropoulos wrote:
  At 12:33 PM 6/25/2004, Ken Jones wrote:
  What you can do is keep the original data, then update and add a domain.
  If it doesn't work, put the old data back. It only is used when adding
   domains not users.
 
  thanks. so my speculation that the 'dom_89' user is sort of a
  'master'  field for such things is correct?

 Yep! It controls just the domain directory layout.
 dom_89 is short for domain_directory_layout_user_id_89
 since 89 was reserved for vpopmail by one of the *nix distributions .

I believe it was freebsd.  Gentoo Linux comes with a vpopmail user by default, 
of 89:
kitchen ~ # id vpopmail
uid=89(vpopmail) gid=89(vpopmail) groups=89(vpopmail)

-Jeremy

-- 
Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies, Inc.
  [EMAIL PROTECTED] ++ www.inter7.com ++ 866.528.3530 ++ 847.492.0470 int'l
kitchen @ #qmail #gentoo on EFnet ++ scriptkitchen.com/qmail



Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-25 Thread Paul Theodoropoulos
At 01:41 PM 6/25/2004, Ken Jones wrote:
On Friday 25 June 2004 02:40 pm, Paul Theodoropoulos wrote:
 At 12:33 PM 6/25/2004, Ken Jones wrote:
 What you can do is keep the original data, then update and add a domain.
 If it doesn't work, put the old data back. It only is used when adding
  domains not users.

 thanks. so my speculation that the 'dom_89' user is sort of a
 'master'  field for such things is correct?
Yep! It controls just the domain directory layout.
dom_89 is short for domain_directory_layout_user_id_89
since 89 was reserved for vpopmail by one of the *nix distributions .
excellent! i tried it, it works - many thanks.
now all i have to do is figure out how to get the two existing domains i 
had to create for customers that are still under the '5' subdir to be under 
'1'. i can't find any way to do it besides deleting and re-creating the 
domains, which isn't exactly elegant...

Paul Theodoropoulos
http://www.anastrophe.com



Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-24 Thread Bill Wichers
 At 12:31 PM 6/23/2004, Jeremy Kitchen wrote:
[snip]
phpmyadmin (http://phpmyadmin.sf.net) makes working with mysql very easy
 :)

 that it does, but it can also lower your effective security, by creating
 Yet Another Thing To Crack.


chmod -R ugo-rwx phpmyadmin/

safety first! ;-) I keep it in a directory that is inside a management
script tree and is secured with Apache's basic username/password auth too.

phpmyadmin is a *great* tool for basic db stuff and editing the occasional
field. Much easier than doing the queries by hand.

 -Bill


*
Waveform Technology
UNIX Systems Administrator




Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-23 Thread Paul Theodoropoulos
well, now it's incremented up to '5'. eesh. what i've found in perusing the 
mysql backend db, is the following:

mysql select * from dir_control where domain = 'dom_89';
++---+---+---+--+--+--+++++++--+--+--+-+
| domain | cur_users | level_cur | level_max | level_start0 | level_start1 
| level_start2 | level_end0 | level_end1 | level_end2 | level_mod0 | 
level_mod1 | level_mod2 | level_index0 | level_index1 | level_index2 | 
the_dir |
++---+---+---+--+--+--+++++++--+--+--+-+
| dom_89 |   201 | 0 | 3 |0 |0 
|0 | 61 | 61 | 61 |  0 
|  2 |  4 |5 |0 |0 | 
5   |
++---+---+---+--+--+--+++++++--+--+--+-+
1 row in set (0.00 sec)

there is no domain dom_89, which suggests to me this may be the 'master 
control' for what overflow subdirectory is to be used - it's the only 
record that has '5' for the value 'the_dir', and '89' is the vpopmail uid/gid.

however, i'm reluctant to make changes to the record, for fear of, well, 
duh - completely destroying my setup with one bad keystroke.

so, if anyone can confirm my speculations, and suggest how to fix it 
(that's right, i've never inserted data manually into a table!), i'd 
appreciate the help.

At 09:51 AM 6/23/2004, Paul Theodoropoulos wrote:
i have a problem (5.3.18, not going to upgrade any time soon). in order to 
scale disk space, i've been symlinking new domain directories to space on 
another filer, e.g.

the main domain directory is /u1/domains. the first 'overflow' 
subdirectory is /u1/domains/0. after i create a new domain in vqadmin, i 
run a small script that moves, for examply, /u1/domains/0/xyz.com to 
/u2/domains/0/xyz.com, and drops a symlink in its place.

in trying to outsmart the system, i pre-created /u2/domains/1, and dropped 
a symlink in /u1/domains, hoping to have all new domains that would go 
into '1' go onto the new filer. that didn't work. vqadmin/vpopmail simply 
created /u1/domains/2/newsite.com. okay, fair enough - i deleted the 
domain i'd just created, then deleted the the symlinked '1' 
directory.  figured i'd just write a new script to move the domain 
directories under '1' just like those for '0'. in the process of trying to 
get this nailed down, vqadmin/vpopmail managed to create /u1/domains/2, 
/u1/domains/3, and now /u1/domains/4. i can't seem to get it to resume 
using '1'.

anyone have a tip for how to fix this? i suppose, in the bigger scheme of 
things, i could just move forward with '4', but having 1 through 3 missing 
lacks symmetry.

thanks in advance.
Paul Theodoropoulos
http://www.anastrophe.com

Paul Theodoropoulos
http://www.anastrophe.com



Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-23 Thread Jeremy Kitchen
On Wednesday 23 June 2004 02:16 pm, Paul Theodoropoulos wrote:
 so, if anyone can confirm my speculations, and suggest how to fix it
 (that's right, i've never inserted data manually into a table!), i'd
 appreciate the help.

phpmyadmin (http://phpmyadmin.sf.net) makes working with mysql very easy :)

-Jeremy

-- 
Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies, Inc.
  [EMAIL PROTECTED] ++ www.inter7.com ++ 866.528.3530 ++ 847.492.0470 int'l
kitchen @ #qmail #gentoo on EFnet ++ scriptkitchen.com/qmail



Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-23 Thread Paul Theodoropoulos
At 12:31 PM 6/23/2004, Jeremy Kitchen wrote:
On Wednesday 23 June 2004 02:16 pm, Paul Theodoropoulos wrote:
 so, if anyone can confirm my speculations, and suggest how to fix it
 (that's right, i've never inserted data manually into a table!), i'd
 appreciate the help.
phpmyadmin (http://phpmyadmin.sf.net) makes working with mysql very easy :)
that it does, but it can also lower your effective security, by creating 
Yet Another Thing To Crack.

but your point is well taken. still - i don't want to hose my entire 
configuration by entering an incorrect digit into the incorrect place, at 
the incorrect time, in the incorrect table.

or something like that. ;^)
Paul Theodoropoulos
http://www.anastrophe.com



Re: [vchkpw] ack, major problem! numbered subdir incremented too high

2004-06-23 Thread Rick Romero
On Wed, 2004-06-23 at 14:35, Paul Theodoropoulos wrote:
 At 12:31 PM 6/23/2004, Jeremy Kitchen wrote:
 On Wednesday 23 June 2004 02:16 pm, Paul Theodoropoulos wrote:
   so, if anyone can confirm my speculations, and suggest how to fix it
   (that's right, i've never inserted data manually into a table!), i'd
   appreciate the help.
 
 phpmyadmin (http://phpmyadmin.sf.net) makes working with mysql very easy :)
 
 that it does, but it can also lower your effective security, by creating 
 Yet Another Thing To Crack.
 
 but your point is well taken. still - i don't want to hose my entire 
 configuration by entering an incorrect digit into the incorrect place, at 
 the incorrect time, in the incorrect table.
 
 or something like that. ;^)


.htaccess:
deny from All
allow from myownIP


If they have access to 'myownIP', you're already compromised.  But
that's just me ;)

Rick

 
 
 Paul Theodoropoulos
 http://www.anastrophe.com